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PREFACE 


This  programming  handbook  presents  the  results  of  work  performed  by  members  of  the 
Telemetry  Group  (TG)  under  Task  TG-83  of  the  Range  Commanders  Council  (RCC).  This 
document  provides  information  to  assist  programmers  in  developing  software  for  use  with 
RCC  Document  106,  Telemetry  Standard,  historically  referred  to  as  Inter-range  Instrumentation 
Group  (IRIG  106).  Therefore  this  document  contains  frequent  references  to  the  IRIG  106 
document,  primarily  Chapter  10,  Digital  Recording  Standard ;  it  also  covers  aspects  of  Chapter  6 
and  Chapter  9. 


NOTE 


This  handbook  is  a  new  document  based  on  (and  correlated  to)  the 
IRIG  106-07  document. 


The  RCC  gives  special  acknowledgement  for  production  of  this  document  to: 

Task  Lead:  Mr.  A1  Berard 

846th  Test  Support  Squadron  (TSS/TSI) 

107  N.  Barrancas  Avenue,  Suite  105 
Eglin  Air  Force  Base  (AFB),  FF  32542 
E-Mail:  alfredo.berard@us.af.mil 


Please  direct  any  questions  to: 

Secretariat,  Range  Commanders  Council 
ATTN:  TEDT-WS-RCC 
1510  Headquarters  Avenue 

White  Sands  Missile  Range,  New  Mexico  88002-5110 
Telephone:  (575)  678-1107,  DSN  258-1107 
E-Mail:  usarmy.wsmr.atec.list.rcc@mail.mil 
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ACRONYMS 


ANSI 

American  National  Standards  Institute 

API 

Application  Programming  Interface 

ARINC 

Aeronautical  Radio,  Incorporated 

CCM 

Command  and  Control  Mnemonic 

CD 

Collision  Detection 

CDB 

Command  Descriptor  Block 

CSDW 

Channel  Specific  Data  Word 

CSMA 

Carrier-Sense  Multiple  Access 

CSR 

Control  and  Status  Register 

DCRsi 

Digital  Cartridge  Recording  System  (a  recording  method  and  digital  data 
interface) 

DITS 

Digital  Information  Transfer  System 

DoD 

Department  of  Defense 

ECL 

Emitter-coupled  Logic 

FCP 

Fibre  Channel  Protocol 

FCPL 

Fibre  Channel  Private  Loop 

FC-PFDA 

Fibre  Channel  Private  Loop  SCSI  Direct  Attach 

GCC 

GNU  Compiler  Collection 

GPS 

Global  Positioning  System 

HSDB 

High  Speed  Data  Bus 

I/O 

Input/Output 

IC 

Intelligence  Community 

IEC 

International  Electrotechnical  Commission 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

IETF 

Internet  Engineering  Task  Force 

IOCTL 

I/O  control 

IP 

Internet  Protocol 

IRIG 

Inter-range  Instrumentation  Group 

iSCSI 

Internet  Small  Computer  Systems  Interface 

iSNS 

Internet  Storage  Name  Service 

ISO 

International  Organization  for  Standards 

IT 

Information  Technology 

ITU 

International  Telecommunications  Union 

IU 

Information  Unit 

KLV 

Key-Length- V  alue 

LB  A 

Logical  Block  Address 

LSB 

Least  Significant  Bit 

LUN 

Logical  Unit  Number 

MAC 

Media  Access  Control 

MAS 

Military  Agency  for  Standardization 

MBR 

Master  Boot  Record 

MISB 

Motion  Imagery  Standards  Board 

MISP 

Motion  Imagery  Standards  Profile 

MPEG 

Moving  Picture  Experts  Group 

MUX 

Multiplexer 

IX 


NADSI 

NATO  Advanced  Data  Storage  Interface 

NATO 

North  Atlantic  Treaty  Organization 

NSG 

National  System  for  Geospatial  Intelligence 

NSIF 

NATO  Secondary  Imagery  Fonnat 

ORB 

Operation  Request  Block 

OS 

Operating  System 

PCM 

Pulse  Code  Modulation 

PDU 

Protocol  Data  Unit 

PS 

Program  Stream 

RCC 

Range  Commanders  Council 

RFC 

Request  For  Comment 

RIU 

Remote  Interface  Unit 

RMM 

Removable  Memory  Module 

RS 

Recommended  Standard 

RTC 

Relative  Time  Counter 

SAM 

SCSI  Architecture  Model 

SBC 

SCSI  Block  Command 

SBP 

Serial  Bus  Protocol 

SCSI 

Small  Computer  Systems  Interface 

SD 

Standard  Definition 

SLP 

Service  Location  Protocol 

SPC 

SCSI  Primary  Commands 

SPT 

SCSI  Pass  Through 

SRB 

SCSI  Request  Block 

STANAG 

Standardization  Agreement 

TCP 

Transmission  Control  Protocol 

TM 

Telemetry 

TMATS 

Telemetry  Attributes  Transfer  Standard 

TS 

Transport  Stream 

UART 

Universal  Asynchronous  Receiver  and  Transmitter 

UDP 

User  Datagram  Protocol 

WMUX 

Weapons  MUX 

XML 

Extensible  Markup  Language 
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CHAPTER  1 

SCOPE 


1.1  General 

The  Telemetry  Group  (TG)  of  the  Range  Commanders  Council  (RCC)  developed  the 
Inter-range  Instrumentation  Group  (IRIG)  106  standard  for  test  range  telemetry  (TM).  The 
primary  purpose  of  the  IRIG  106,  published  as  RCC  Document  106,  Telemetry  Standard,  is  to 
define  a  common  framework  for  test  range  instrumentation  to  ensure  test  range  interoperability. 
The  RCC  periodically  revises  and  reissues  IRIG  106.  A  specific  version  of  IRIG  106  is  suffixed 
with  the  last  two  digits  of  the  year  it  was  released.  For  example,  IRIG  106-07  refers  to  the 
version  of  IRIG  106  released  in  2007. 


The  IRIG  106  is  composed  often  chapters,  each  devoted  to  a  different  element  of  the 
telemetry  system  or  process.  One  of  the  major  topics  of  the  IRIG  106  standard  is  Chapter  10,  the 
Digital  Recording  Standard.  Chapter  10  defines  the  interfaces  and  operational  requirements  for 
digital  data  recording  devices.  Chapter  10  also  references  elements  of  Chapter  6  (Digital 
Cassette  Helical  Scan  Recorder/Reproducer,  Multiplexer/Demultiplexer,  Tape  Cassette,  and 
Recorder  Control  and  Command  Mnemonics  Standards)  and  Chapter  9  (Telemetry  Attributes 
Transfer  Standard). 

Chapter  10  is  comprehensive  in  its  scope.  The  purpose  of  this  programming  handbook  is 
to  serve  as  an  adjunct  to  the  IRIG  106  standard  to  assist  the  computer  programmer  when  writing 
software  for  operating  IRIG  106  Chapter  10  standard  digital  recorders,  and  when  analyzing  data 
from  these  recorders.  A  prior  working  knowledge  of  Chapter  9,  Chapter  10,  and  applicable 
sections  of  Chapter  6,  is  essential. 


1.2  Document  Layout 

This  programming  handbook  addresses  specific  topics  of  Chapter  6,  Chapter  9,  and 
Chapter  10  of  IRIG  106  which  are  important  to  the  programmer.  Algorithms  and  data  structures 
are  presented  to  assist  the  programmer  in  correctly  interpreting  IRIG  106  and  implementing 
software  for  use  with  digital  data  recorders.  In  particular,  data  structures  are  defined  in 
American  National  Standards  Institute  (ANSI)  C  for  data  defined  in  IRIG  106.  Guidance  is  also 
offered  on  specific  programming  techniques  as  follows: 


a.  Chapter  3: 

b.  Chapter  4: 

c.  Chapter  5: 

d.  Chapter  6: 

e.  Chapter  7: 

f.  Appendix  A: 

g.  Appendix  B: 

h.  Appendix  C: 


Reading  and  interpreting  Chapter  9  recorder  configuration  files. 
Data  retrieval  over  the  standard  recorder  interfaces. 

Recorder  command  and  control. 

Data  file  interpretation. 

IRIG  106  standard  conformance  issues. 

Selected  Source  Code  Files 
Example  Program  -  Calculate  Histogram 

Example  Program  -  Decode  Telemetry  Attributes  Transfer  Standard 
(TMATS) 
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1.3  Document  conventions 

In  the  sections  that  follow,  example  computer  source  code  and  data  structures  are 
presented.  All  computer  code  is  written  in  ANSI  C.  Occasionally,  C-like  pseudo-code  is  used  to 
demonstrate  an  algorithm  more  succinctly  than  strictly  “legal”  C.  These  instances  will  be 
obvious  from  the  context. 

Different  programming  languages  have  different  default  sized  variables.  Even  different 
compilers  for  a  single  language  like  C  will  have  different  variable  sizes.  Many  variables  and 
structures  need  to  be  represented  with  specific  sized  variables.  This  document,  with  the  source 
code  that  accompanies  it,  defines  standard  sized  variable  types.  The  variable  type  naming 
convention  used  is  the  same  convention  used  in  later  versions  of  the  GNU  Compiler  Collection 
(GCC)  C  run-time  library.  The  variable  type  names  used  are  shown  in  Table  1-1. 


TABLE  1-1.  STANDARD  SIZED  VARIABLE  TYPES 

int8  t 

integer,  signed, 

8  bit 

intl6  t 

integer,  signed, 

16  bit 

int32  t 

integer,  signed, 

32  bit 

int64  t 

integer,  signed, 

64  bit 

uint8  t 

integer,  unsigned, 

8  bit 

uintl6  t 

integer,  unsigned, 

16  bit 

uint32  t 

integer,  unsigned, 

32  bit 

uint64  t 

integer,  unsigned, 

64  bit 

Hungarian  notation  is  used  for  variable  and  structure  naming  to  help  keep  variable  type 
and  meaning  clear.  The  Hungarian  prefixes  used  in  the  example  code  are  shown  in  Table  1-2. 


TABLE  1-2.  HUNGARIAN  NOTATION  PREFIXES 

i 

Signed  integer 

u 

Unsigned  integer 

b 

Boolean  flag 

ch 

Character 

by 

Byte 

sz 

Null  terminated  array  of  char 

en 

Enumerated  type 

m 

Variable  with  module  scope 

Variable  with  global  scope 

SU 

Structure  variable 

Su 

Structure  name 

a 

Array  of... 

p 

Pointer  to... 
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CHAPTER  2 

APPLICABLE  DOCUMENTS 

2.1  Government  documents 

a.  Range  Commanders  Council  (RCC)  Document  106-07,  Telemetry  Standard. 

b.  RCC  Document  118-06,  Test  Methods  for  Telemetry  Systems  and  Subsystems. 

c.  MIL-STD- 1 553B,  Aircraft  Internal  Time  Division  Command/Response  Multiplex 
Data  Bus,  United  States  (U.S.)  Department  of  Defense  (DoD),  21  September  1978. 

d.  MIL-STD-2500B,  National  Imagery  Transmission  Format  Version  2.1  for  the 
National  Imagery  Transmission  Format  Standard,  U.S.  DoD,  22  August  1997. 

e.  16PP362A,  Weapons  Multiplexer  (WMUX)  Protocol  (revision  C),  46  Test  Wing 
(46TW),  Eglin  Air  Force  Base  (AFB). 

f.  Standardization  Agreement  (STANAG)  No.  4545,  North  Atlantic  Treaty 
Organization  (NATO)  Secondary  Imagery  Format  (NSIF),  Military  Agency  for 
Standardization  (MAS)  /  NATO,  27  November  1998. 

g.  STANAG  No.  4575,  NATO  Advanced  Data  Storage  Interface  (NADSI),  MAS  / 
NATO. 

h.  Motion  Imagery  Standards  Profile  (MISP,  Version  4.4),  DoD  /  Intelligence 
Community  /  National  System  for  Geospatial  Intelligence  (DoD/IC/NSGI),  Motion 
Imagery  Standards  Board  (MISB),  13  December  2007. 

2.2  Non-government  publications 

a.  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  Standard  802.3  -  2005, 
Carrier-Sense  Multiple  Access/Collision  Detection  (CSMA/CD)  Access  Method  and 
Physical  Layer  Specifications. 

b.  IEEE  Standard  1394b  -  2002,  IEEE  Standard  for  a  High-Performance  Serial  Bus  - 
Amendment  2. 

c.  International  Organization  for  Standards  /International  Electrotechnical  Commission 
(ISO/IEC)  13818-1:1996,  Information  Technology  -  Generic  Coding  of  Moving 
Pictures  and  Associated  Audio  Information:  Systems. 

d.  ISO/IEC  13818-2:1996,  Information  Technology  -  Generic  Coding  of  Moving 
Pictures  and  Associated  Audio  Information:  Video. 

e.  ISO/IEC  13818-3:1996,  Information  Technology  -  Generic  Coding  of  Moving 
Pictures  and  Associated  Audio  Information:  Audio. 

f.  ISO/IEC  13213: 1994,  Control  and  Status  Register  (CSR)  Architecture  for 
Microcomputer  Buses. 

g.  ISO/IEC  14776-412:2006,  Small  Computer  System  Interface  (SCSI)  Architecture 
Model  2  (SAM-2). 

h.  ISO/IEC  14776-452:2005,  SCSI  Primary  Commands  2  (SPC-2). 

i.  ISO/IEC  14776-322:2007,  SCSI  Block  Commands  2  (SBC-2). 

j .  ISO/IEC  14776-232:200 1 ,  Serial  Bus  Protocol  2  (SBP-2). 

k.  ISO/IEC  14776-222:2005,  Fibre  Channel  Protocol  for  SCSI,  Second  Version 
(FCP-2). 
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l.  International  Telecommunications  Union,  Telecommunication  Standardization  Sector 
(ITU-T)  Rec.  H.262,  Information  Technology  -  Generic  Coding  of  Moving  Pictures 
and  Associated  Audio  Information:  Video,  AMENDMENT  1:  Content  Description 
Data,  2000. 

m.  ITU-T  Rec.  H.264,  Advanced  Video  Coding  for  Generic  Audiovisual  Services,  2007. 

n.  Plug  and  Play  Design  Specification  for  IEEE  1394  Ver.  1.0b,  Microsoft  Corporation, 
17  October,  1997. 

o.  Aeronautical  Radio,  Incorporated  (ARINC)  429P 1-17,  Mark  33  Digital  Information 
Transfer  System  (DITS),  2004. 
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CHAPTER  3 

RECORDER  SETUP  AND  CONFIGURATION 

Chapter  9  of  IRIG  106  defines  the  Telemetry  Attributes  Transfer  Standard  (TMATS). 
Historically,  TMATS  has  been  used  as  a  shorthand  way  of  documenting  and  describing  recorded 
data  to  facilitate  future  data  interpretation  and  reduction.  In  the  context  of  Chapter  10,  TMATS 
is  still  used  to  document  recorded  data,  but  is  also  used  for  recorder  setup  and  configuration. 

The  TMATS  text  is  designed  to  be  user  friendly  and  it  is  also  structured  to  be  machine 
parsable.  Each  attribute  appears  in  the  TMATS  file  as  a  unique  code  name  and  data  item  pair. 
The  code  name  appears  first,  delimited  by  a  colon.  The  data  item  follows,  delimited  by  a 
semicolon.  Therefore,  an  attribute  has  the  fonn: 

CODE : DATA; 

Note:  Although  not  required,  lines  may  be  terminated  with  a  carriage  return  and  line  feed 
to  improve  readability. 

TMATS  attributes  are  logically  arranged  in  a  hierarchical  tree  structure.  Figure  9-1  in  the 
IRIG  Chapter  9  standard  shows  this  attribute  tree  structure.  Unlike  other  markup  languages, 
such  as  Extensible  Markup  Language  (XML),  the  structure  of  the  attribute  tree  is  not  inherent  in 
the  position,  structure,  or  syntax  of  individual  TMATS  lines.  Instead,  the  hierarchical 
connections  are  deduced  by  matching  attribute  names  from  different  tree  levels.  For  example, 
TMATS  “R”  attributes  are  linked  to  the  corresponding  TMATS  “G”  attribute  by  matching  the 
“R-m\ID”  attribute  such  as  “R-l\ID:MyDataSource;”  with  the  corresponding 
“G\DSI-n”  attribute  such  as  “G\DSI-1 :  MyDataSource ;  An  example  of  a  portion  of  a 
TMATS  attribute  tree  is  shown  in  Figure  3-1.  Chapter  9  defines  the  specific  linking  fields  for 
the  various  levels  of  the  TMATS  attribute  tree. 
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i—  (G)  Program  Name  -  A-10_9£9-ATP . tmt 
(G)  TMATS  Version  -  2 
0  (G\DSI-1)  Data  Source  ID  -  DATASOORCE 
(GXDST-l)  Data  Source  Type  -  OTH 
(R-1UD)  ID  -  DATASOURCE 

E]  (R-1\DSI-1)  Data  Source  ID  -  TimelnChanl 
(R-1\DST-1)  Channel  Type  -  TIMIN 
(R-1XTK1-1)  Track  Number  -  1 
(R-1\CHE-1)  ENABLED 

0  (R-1XDSI-2)  Data  Source  ID  -  VoicelnChanl 
(R-1XDST-2)  Channel  Type  -  ANAIN 
(R-l\TKl-2)  Track  Number  -  2 
(R-1VCHE-2)  DISABLED 

0  (R-l\DSI-3)  Data  Source  ID  -  1553InChanl 
(R-1VDST-3)  Channel  Type  -  1SS3IN 
(R-1XTK1-3)  Track  Number  -  11 
(R-1XCHE-3)  ENABLED 
i  6  (M-1\BB\DLN)  DLN  -  1553InChanl 
h  (M-1\BSG1)  PCM 
L  (M-1UDI  1553InChanl 
0  (R-l\DSI-4)  Data  Source  ID  -  1553InChan2 

0  (R-1XDSI-5)  Data  Source  ID  -  1553InChan3 

0  (R-1XDSI-6)  Data  Source  ID  -  1553InChan4 

0  (R-1XDSI-7)  Data  Source  ID  -  PCMInChanl 

0  (R-1XDSI-8)  Data  Source  ID  -  PCMInChan2 

0  (R-1XDSI-9)  Data  Source  ID  -  PCMInChan3 

0  (R-1XDSI-10)  Data  Source  ID  -  PCMInChan4 


Figure  3-1.  Example  TMATS  attribute  tree. 

Attribute  lines  can  be  easily  parsed  using  the  string  tokenizer  function  strtok  ( )  in  the 
C  run  time  library.  An  example  approach  outline  for  TMATS  parsing  is  shown  in  Figure  3-2. 

The  TMATS  attribute  line  is  stored  in  the  null  terminated  character  array  szLine  [  ] .  The  code 
name  string  is  pointed  to  by  szCodeName  and  the  data  item  value  is  pointed  to  by 
szDataltem.  Specific  parsers  are  called  for  specific  attribute  types,  indicated  by  the  first  letter 
of  the  code  name.  After  all  TMATS  attributes  are  read,  they  are  linked  into  a  hierarchical  tree. 

A  more  complete  example  of  TMATS  parsing  is  presented  in  Appendix  C. 
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char  szLine  [2048] ; 

char  *  szCodeName; 

char  *  szDataltem; 

//  Split  the  line  into  left  hand  and  right  hand  sides 
szCodeName  =  strtok (szLine, 
szDataltem  =  strtok (NULL, 

//  Determine  and  decode  different  TMATS  types 
switch  (szCodeName [0] ) 

{ 

case  ' G'  :  //  Decode  General  Information 
break; 

case  ' B'  :  //  Decode  Bus  Data  Attributes 
break; 

case  'R'  :  //  Decode  Tape/Storage  Source  Attributes 

break; 

case  ' T ’  :  //  Decode  Transmission  Attributes 

break; 

case  'M'  :  //  Decode  Multiplexing/Modulation  Attributes 

break; 

case  ' P '  :  //  Decode  PCM  Format  Attributes 

break; 

case  ' D'  :  //  Decode  PCM  Measurement  Description 
break; 

case  'S'  :  //  Decode  Packet  Format  Attributes 

break; 

case  'A'  :  //  Decode  PAM  Attributes 

break; 

case  ' C '  :  //  Decode  Data  Conversion  Attributes 

break; 

case  'H'  :  //  Decode  Airborne  Hardware  Attributes 

break; 

case  'V'  :  //  Decode  Vendor  Specific  Attributes 

break; 

default  : 
break; 

}  //  end  decoding  switch 

//  Now  link  the  various  records  together  into  a  tree 

vConnectRtoG (...); 

vConnectMtoR (...); 

vConnectBtoM (...); 

Figure  3-2.  TMATS  attribute  parser  example  code. 

The  two  basic  types  of  attribute  code  names  are  single  entry  and  multiple  entry.  Single 
entry  attributes  are  those  for  which  there  is  only  one  data  item  and  appear  once  in  TMATS.  For 
example: 

G\PN:EW  EFFECTIVENESS; 
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Multiple  entry  attributes  may  appear  multiple  times.  They  are  distinguished  by  a  numeric 
identifier  preceded  by  a  hyphen.  For  example: 

GYDSI- 1 :  Aircraft; 

G\DSI-2:Missile; 

G\DSI-3:  Target; 

Some  attributes  can  appear  multiple  times  at  multiple  levels.  For  example,  the  Message 
Data  Sub-Channel  Name  attribute  “R-x\MCNM-n-m”  may  appear  associated  with  multiple 
recorder  groups  (“x”),  multiple  message  data  channels  (“n”),  and  with  multiple  subchannels 


Chapter  9  of  IRIG  106  identifies  quite  a  few  required  Recorder  TMATS  attributes. 
These  attributes  are  necessary  to  ensure  correct  recorder  setup,  and  subsequent  data 
interoperability.  For  correct  TMATS  parsing  and  interpretation,  an  important  required  attribute 
is  the  “G\106”  attribute.  This  attribute  identifies  the  version  of  IRIG  106  to  use  when 
interpreting  the  TMATS  information.  This  attribute  only  identifies  the  TMATS  version.  The 
Chapter  10  standard  version  is  specified  in  the  TMATS  setup  record  in  the  recorded  data  file 
described  in  Paragraph  6.5.2  of  this  document. 

Chapter  9  states  that  attributes  may  appear  in  any  order.  Chapter  10,  however,  requires 
some  specific  TMATS  comment  attributes  follow  other  specific  modified  TMATS  attributes  for 
modified  data  files.  This  requirement  complicates  TMATS  machine  parsing  considerably. 
When  reading  and  decoding  TMATS,  a  parser  must  maintain  the  most  recent  recorder  data 
channel  state  so  that  when  a  comment  attribute  is  encountered,  it  can  be  associated  with  the 
correct  recorder  channel.  When  writing  TMATS,  the  appropriate  comments  must  follow  the 
appropriate  attribute  records.  See  Chapter  10  for  specific  TMATS  attribute  position  and  order 
requirements. 
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CHAPTER  4 

DATA  RETRIEVAL 

4.1  Small  Computer  Systems  Interface  (SCSI)  Protocol 

Recorded  data  from  a  Chapter  10  recorder  is  retrieved  by  transferring  it  to  a  host 
computer  over  one  of  several  interfaces  provided  by  the  recorder.  Chapter  10  requires  that  each 
Removable  Memory  Module  (RMM)  provide  an  IEEE  1394b  standard  data  download  port. 
Chapter  10  also  requires  that  each  recorder  provide  either  a  Fibre  Channel  or  IEEE  1394b  data 
download  port  and,  optionally,  an  Ethernet  download  port. 

The  protocol  for  data  download  over  the  various  interface  types  is  the  Small  Computer 
Systems  Interface  (SCSI)  block  transfer  protocol.  Overall  SCSI  operation  is  defined  in  the  SCSI 
Architecture  Model  2  (SAM-2)  document.  Common  commands  are  defined  in  the  SCSI  Primary 
Commands  (SPC-2)  document.  Commands  for  block  devices  are  defined  in  SCSI  Block 
Commands  2  (SBC-2)  document. 

The  SCSI  architecture  is  a  client-server  model.  The  client  is  the  user  application  (the 
“initiator”),  requesting  services  (status,  data,  etc.)  from  the  SCSI  server  device  (the  “target”).  An 
application  client  is  independent  of  the  underlying  interconnect  and  SCSI  transport  protocol. 

Each  SCSI  target  is  identified  by  a  target  device  name.  Targets  are  addressed  using  the  target 
device  name.  Different  transports  support  different  methods  for  uniquely  naming  SCSI  targets. 
Each  target  device  also  supports  one  or  more  Logical  Unit  Numbers  (LUNs).  Logical  Unit 
Numbers  are  used  to  support  different  services  from  a  single  SCSI  target  device.  For  example, 
an  RMM  provides  disk  file  access  using  LUN  0,  and  Real  Time  Clock  access  using  LUN  1. 

The  SAM  defines  a  Command  Descriptor  Block  (CDB)  structure  along  with  associated 
user  input  and  output  buffers.  The  CDBs  are  used  to  issue  commands  to  SCSI  devices.  The 
SCSI  protocol  defines  a  large  number  of  commands  to  support  a  wide  range  of  devices.  The 
Chapter  10  standard  only  requires  a  small  subset  of  the  complete  SCSI  command  set  to  be 
implemented  to  support  the  RMM  and  remote  data  access  block  transfer  device.  A  CDB  can  be 
6,  10,  12,  or  16  bytes  in  length.  Chapter  10  currently  only  requires  6  and  10-byte  CDBs.  Note 
that  multi-byte  CDB  values  such  as  a  Logical  Block  Address  (LB A)  are  big  endian  in  the  CDB 
and  require  writing  to  the  CDB  a  byte  at  a  time  from  a  little  endian  processor  to  write  the  multi¬ 
byte  values  in  proper  order. 

The  SCSI  INQUIRY  command  is  used  to  query  the  SCSI  device  about  its  capabilities. 
The  structure  for  the  INQUIRY  CDB  is  shown  in  Figure  4-1.  The  structure  for  the  Control  field 
is  shown  in  Figure  U2.  The  data  download  interface  is  required  to  support  the  standard 
INQUIRY  response  shown  in  Figure  U3.  Also  required  are  the  Supported  Vital  Product  page, 
Unit  Serial  Number  page,  and  Device  Identification  page. 
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struct  SuCdblnquiry 
{ 


uint8  t 

uOpCode; 

// 

Operation  code  =  0x12 

uint8  t 

bEVPD  : 

1; 

// 

Enable  vital  product  data 

uint8  t 

bCmdDt  : 

1; 

// 

Command  support  data 

uint8  t 

Reservedl  : 

6; 

// 

uint8  t 

uPageOpCode; 

// 

Page  or  operation  code 

uint8  t 
uint8  t 

Reserved2 ; 
uAllocLength; 

// 

// 

Allocation  length 

struct  SuCdbControl  suControl; 
}  ; 


Figure  4- 1 .  SCSI  INQUIRY  CDB  structure. 


struct  SuCdbControl 
{ 


uint8 

t 

bLink  :  1; 

uint8 

t 

Obsolete  :  1; 

uint8 

t 

bNACA  :  1 

uint8 

t 

Reserved  :  3; 

uint8 

t 

uVendor  :  2; 

}; 

Figure  4-2.  SCSI  CDB  Control  field  structure. 
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struct  SuCdblnquiryStdData 
/ 

l 

uint8  t 

uPeriphType 

5; 

// 

Peripheral  device  type 

uint8  t 

uPeriphQual 

3; 

// 

Peripheral  qualifier 

uint8  t 

uReservedl 

7; 

uint8  t 

bRMB 

1; 

// 

Removable  medium 

uint8  t 

uVersion; 

// 

Version 

uint8  t 

uFormat 

4; 

// 

Response  data  format 

uint8  t 

bHiSup 

1; 

// 

Hierarchical  support 

uint8  t 

bNormACA 

1; 

// 

Support  normal  ACA  bit 

uint8  t 

uReserved2 

1; 

uint8  t 

bAERC 

1; 

// 

Asynchronous  event  reporting 

cap 

uint8  t 

uAddLength; 

// 

Length  of  additional 

parameters 

uint8  t 

uReserved3 

7; 

uint8  t 

bSCCS 

1; 

// 

Embedded  storage  array 

supported 

uint8  t 

bAddrl 6 

1; 

// 

Not  used 

uint8  t 

uReserved4 

2; 

uint8  t 

bMChngr 

1; 

// 

Medium  changer 

uint8  t 

bMultiP 

1; 

// 

Multi-port  device 

uint8  t 

bVSl 

1; 

// 

Vendor  specific 

uint8  t 

bEncServ 

1; 

// 

Enclosure  service 

uint8  t 

bBQue 

1; 

// 

Basic  queing 

uint8  t 

bVS2 

1; 

// 

Vendor  specific 

uint8  t 

bCmdQue 

1; 

// 

Command  queuing  supported 

uint8  t 

uReserved5 

1; 

uint8  t 

bLinked 

1; 

// 

Linked  commands  supported 

uint8  t 

bSync 

1; 

// 

Not  used 

uint8  t 

bWBusl 6 

1; 

// 

Not  used 

uint8  t 

uReserved6 

1; 

uint8  t 

bRelAddr 

1; 

// 

Relative  addressing  supported 

uint8  t 

uVendorlD [ 8 ] ; 

// 

uint8  t 

uProductID [16^ 

; 

// 

uint8  t 

}; 

uProductRev [ 4 

; 

// 

Figure  4-3.  SCSI  INQUIRY  data  structure. 


The  SCSI  READ  CAPACITY  command  is  used  to  query  the  disk  device  about  its  size. 
The  structure  for  the  READ  CAPACITY  CDB  is  shown  in  Figure  4-4.  This  command  returns 
the  number  of  available  logical  blocks  and  the  logical  block  size  in  bytes,  shown  in  Figure  4-5. 
Note  that  returned  values  are  big  endian  and  must  be  byte  swapped  before  they  can  be  used  on  a 
little  endian  processor. 
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struct  SuCdbReadCapacitylO 
{ 


uint8 

t 

uOpCode; 

// 

Operation  code 

=  0x25 

uint8 

t 

uReservedl ; 

// 

uint8 

t 

uLBA  3  MSB; 

// 

Logical 

block 

address , 

MSB 

uint8 

t 

uLBA  2; 

// 

Logical 

block 

address 

uint8 

t 

uLBA  1; 

// 

Logical 

block 

address 

uint8 

t 

uLBA  0  LSB; 

// 

Logical 

block 

address , 

LSB 

uint8 

t 

uReserved2 ; 

// 

uint8 

t 

uReserved3 ; 

// 

uint8 

t 

bPMI 

:  1; 

// 

Partial 

medium 

.  indicator 

uint8 

t 

uReserved3 

:  7; 

// 

struct  SuCdbControl  suControl; 
}  ; 


Figure  4-4.  SCSI  READ  CAPACITY  CDB  structure. 


struct  SuCdbReadCapacityData 

{ 

uint64  t  uBlocks;  //  Logical  blocks  (big  endian!) 

uint64  t  uBlockSize;  //  Block  size  (big  endian!) 

}  ; 


Figure  4-5.  SCSI  READ  CAPACITY  data  structure. 

The  SCSI  READ  command  is  used  to  read  logical  blocks  of  data  from  the  disk  device. 
The  SCSI  protocol  provides  five  different  READ  commands  with  various  capabilities  and  sizes 
of  the  CDB.  The  Chapter  10  standard  only  requires  the  10  byte  variant  of  the  READ  command. 
The  structure  for  the  READ  CDB  is  shown  in  Figure  4-6.  This  command  returns  the  data  from 
the  requested  logical  blocks. 
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struct  SuCdbReadlO 
{ 


uint8 

t 

uOpCode; 

// 

Operation  code  =  0x28 

uint8 

t 

bReservedl 

1; 

// 

uint8 

t 

bFUA  NV 

1; 

// 

Force  unit  access  non- 

volatile 

uint8 

t 

Reserved2 

1; 

// 

uint8 

t 

bFUA 

1; 

// 

Force  unit  access 

uint8 

t 

bDPO 

1; 

// 

Disable  page  out 

uint8 

t 

bRdProtect 

3; 

// 

Read  protect 

uint8 

t 

uLBA  3  MSB; 

// 

Logical  block  address. 

MSB 

uint8 

t 

uLBA  2; 

// 

Logical  block  address 

uint8 

t 

uLBA  1; 

// 

Logical  block  address 

uint8 

t 

uLBA  0  LSB; 

// 

Logical  block  address. 

LSB 

uint8 

t 

uGroupNum 

5; 

// 

Group  number 

uint8 

t 

Reserved3 

3; 

// 

uint8 

t 

uTransLength  1  MSB; 

// 

Transfer  length,  MSB 

uint8 

t 

uTransLength  0  LSB; 

// 

Transfer  length,  LSB 

struct  SuCdbControl  suControl; 
}  ; 


Figure  4-6.  SCSI  READ(10)  CDB  structure. 

4.1.1  IEEE  1394.  IEEE  1394  defines  the  Serial  Bus  Protocol  (SBP-2)  for  transporting  CDBs 
and  data  over  a  1394  bus  to  a  SCSI  target.  The  basic  unit  of  information  in  SBP-2  is  the 
Operation  Request  Block  (ORB).  The  ORBs  encapsulate  the  information  in  SCSI  CDBs  and 
input/output  buffers,  as  well  as  additional  information  needed  by  the  1394  bus.  The  1394  bus 
operates  by  exposing  a  shared  memory  address  space,  negotiated  during  device  initialization. 
CDBs  carried  within  SBP  packets  are  written  to  the  SCSI  target  device  shared  memory,  and 
associated  data  is  written  to  and  read  from  shared  memory. 

When  interfacing  to  an  RMM,  LUN  0  is  used  for  disk  access.  LUN  1  is  used  for 
interfacing  to  the  RMM  Real  Time  Clock. 

When  interfacing  to  a  recorder,  LUN  0  is  used  for  disk  access. 

4. 1 .2  Fibre  Channel.  Fibre  Channel  defines  the  Fibre  Channel  Protocol  (FCP)  for  transporting 
CDBs  and  data  over  a  Fibre  Channel  bus  to  a  SCSI  target.  The  basic  unit  of  information  in  FCP 
is  the  Information  Unit  (IU).  FCP  defines  several  types  of  IUs  used  to  communicate  with  SCSI 
targets.  Fibre  Channel  also  defines  the  Fibre  Channel  Private  Loop  (FCPL)  SCSI  Direct  Attach 
(FC-PLDA)  protocol.  The  FC-PLDA  further  defines  the  implementation  of  SCSI  over  Fibre 
Channel.  Chapter  10  requires  conformance  to  FC-PLDA. 

4.1.3  Internet  Small  Computer  Systems  Interface  (iSCSI).  The  Internet  Engineering  Task 
Force  (IETF)  has  published  Request  For  Comment  (RFC)  3270  defining  the  iSCSI  protocol  for 
transporting  CDBs  over  Transmission  Control  Protocol/Internet  Protocol  (TCP/IP)  based 
network  to  an  SCSI  target.  Chapter  10  identifies  iSCSI  as  the  standard  protocol  for  recorder  data 
access  over  Ethernet.  The  basic  unit  of  information  in  iSCSI  is  the  Protocol  Data  Unit  (PDU). 
The  PDUs  encapsulate  the  information  in  SCSI  CDBs  and  input/output  buffers  as  well  as 
additional  information  needed  by  the  underlying  IP  network.  The  PDUs  are  transported  over  a 
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TCP  connection,  usually  using  well  known  port  number  860  or  3260.  The  actual  port  number 
used  is  not  specified  in  Chapter  10. 

For  an  iSCSI  initiator  to  establish  an  iSCSI  session  with  an  iSCSI  target,  the  initiator 
needs  the  IP  address,  the  TCP  port  number,  and  the  iSCSI  target  name  information.  There  are 
several  methods  that  may  be  used  to  find  targets.  An  iSCSI  supports  the  following  discovery 
mechanisms: 

a.  Static  Configuration:  This  mechanism  assumes  that  the  IP  address,  TCP  port,  and  the 
iSCSI  target  name  information  are  already  available  to  the  initiator.  The  initiators 
need  to  perform  no  discovery  in  this  approach.  The  initiator  uses  the  IP  address  and 
the  TCP  port  information  to  establish  a  TCP  connection;  it  also  uses  the  iSCSI  target 
name  information  to  establish  an  iSCSI  session.  This  discovery  option  is  convenient 
for  small  iSCSI  setups. 

b.  SendTargets:  This  mechanism  assumes  that  the  target's  IP  address  and  TCP  port 
information  are  already  available  to  the  initiator.  The  initiator  then  uses  this 
information  to  establish  a  discovery  session  to  the  Network  Entity.  The  initiator  then 
subsequently  issues  the  SendTargets  text  command  to  query  information  about  the 
iSCSI  targets  available  at  the  particular  Network  Entity  (IP  address). 

c.  Zero-Configuration:  This  mechanism  assumes  that  the  initiator  does  not  have  any 
information  about  the  target.  In  this  option,  the  initiator  can  either  multicast 
discovery  messages  directly  to  the  targets  or  it  can  send  discovery  messages  to 
storage  name  servers.  Currently,  there  are  many  general  purpose  discovery 
frameworks  available.  Service  Location  Protocol  (SLP  [RFC2608]  and  Internet 
Storage  Name  Service  (iSNS  [iSNS])  are  two  popular  discovery  protocols. 

Target  discovery  is  not  specified  in  Chapter  10. 

When  interfacing  to  a  recorder,  LUN  0  or  LUN  32  is  used  for  disk  access.  For  command 
and  control,  LUN  1  or  LUN  33  is  used. 

4.2  Software  Interface 

All  recorder  data  download  interfaces  appear  as  SCSI  block  Input/Output  (I/O)  devices, 
and  respond  to  the  subset  of  SCSI  commands  set  forth  in  Chapter  10.  However,  different 
operating  systems  provide  vastly  different  types  of  Application  Programming  Interfaces  (API) 
for  communicating  with  recorders  and  RMMs  over  the  various  data  download  interfaces 
specified  in  Chapter  10. 

The  Microsoft  Windows  device  driver  environment  helps  remove  a  lot  of  complexity 
from  communicating  over  the  various  data  interfaces.  Windows  plug  and  play  drivers  are  able  to 
discover  various  types  of  SCSI  devices  connected  to  them,  to  initialize  and  configure  them,  and 
then  offer  a  single  programming  interface  for  user  application  programs. 

The  interface  used  by  Windows  application  to  send  SCSI  commands  to  a  SCSI  device  is 
called  SCSI  Pass  Through  (SPT).  Windows  applications  can  use  SPT  to  communicate  directly 
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with  SCSI  devices  using  the  Win32  API  Device  I  oControl  ( )  call  and  the  appropriate  I/O 
control  (IOCTL)  code. 

Before  any  IOCTLs  can  be  sent  to  a  SCSI  device,  a  handle  for  the  device  must  be 
obtained.  The  Win32  API  CreateFile  ( )  is  used  to  obtain  this  handle  and  to  define  the 
sharing  mode  and  the  access  mode.  Note  that  Windows  may  require  security  priviledges  above 
those  normally  granted  to  a  regular  user  to  call  CreateFile  ( ) .  The  access  mode  must  be 
specified  as  (GENERICREAD  |  GENERIC  WRITE).  The  key  to  obtaining  a  valid  handle  is  to 
supply  the  proper  filename  for  the  device  that  is  to  be  opened. 

For  Chapter  10  SCSI  devices,  the  SCSI  class  driver  defines  an  appropriate  name.  If  the 
device  is  unclaimed  by  a  SCSI  class  driver  (the  usual  case),  then  a  handle  to  the  SCSI  port  driver 
is  required.  The  filename  in  this  case  is  "\\  .  \ScsiN :  ",  where  N  =  0,  1,2,  etc.  The  number  N 
corresponds  to  the  SCSI  host  adapter  card  number  that  controls  the  desired  SCSI  device.  When 
the  SCSI  port  name  is  used,  the  Win32  application  must  set  the  proper  Pathld,  Target  Id, 
and  LUN  in  the  SCSI  pass  through  structure. 

Once  a  valid  handle  to  a  SCSI  device  is  obtained,  then  appropriate  input  and  output 
buffers  for  the  requested  IOCTL  must  be  allocated  and,  in  some  cases,  filled  in  correctly. 

There  are  several  IOCTLs  that  the  SCSI  port  driver  supports;  these  include: 

a.  IOCTL_SCSI_GET_INQUIRY_DATA 

b.  IOCTL_SCSI_GET_CAP ABILITIES 

c.  IOCTL_SCSI_PASS_THROUGH 

d.  IOCTL_SCSI_PASS_THROUGH_DIRECT 

The  IOCTL_SCSI_GET_INQUIRY_DATA  returns  a  SCSI_ADAPTER_BUS_INFO 

structure  for  all  devices  that  are  on  the  SCSI  bus.  The  structure  member,  BusData,  is  a 
structure  of  type  SCSI_BUS_DATA;  it  contains  an  offset  to  the  SCSI  Inquiry  data,  which  is  also 
stored  as  a  structure,  SCSI_INQUIRY_DATA. 

The  SCS  I_INQUIRY_DATA  structure  contains  a  member  named  DeviceClaimed. 
DeviceClaimed  indicates  whether  or  not  a  class  driver  has  claimed  this  particular  SCSI  device. 

If  a  device  is  claimed,  all  SCSI  pass  through  requests  must  be  sent  first  through  the  class  driver, 
which  will  typically  pass  the  request  unmodified  to  the  SCSI  port  driver.  If  the  device  is 
unclaimed,  the  SCSI  pass  through  requests  are  sent  directly  to  the  SCSI  port  driver. 

For  IOCTL_SCSI_GET_INQUIRY_DATA,  no  data  is  sent  to  the  device;  data  is  only 
read  from  the  device.  Set  lpInBuffer  to  NULL  and  nlnBufferSize  to  zero.  The  output  buffer 
might  be  quite  large,  as  each  SCSI  device  on  the  bus  will  provide  data  that  will  fill  three 
structures  for  each  device:  SCS  I_ADAPTER_BUS_INFO,  SCS  I_BUS_DATA,  and 
SCSI_INQUIRY_DATA.  Allocate  a  buffer  that  will  hold  the  information  for  all  the  devices  on 
that  particular  SCSI  adapter.  Set  lpOutBuffer  to  point  to  this  allocated  buffer  and 
nOutBufferSize  to  the  size  of  the  allocated  buffer. 
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The  IOCTL_SCSI_GET_CAP ABILITIES  returns  an  IOSCSICAP ABILITIES 
structure.  This  structure  contains  valuable  information  about  the  capabilities  of  the  SCSI 
adapter.  Two  items  of  note  are  the  MaximumTransferLength,  which  is  a  byte  value  indicating 
the  largest  data  block  that  can  be  transferred  in  a  single  SCSI  Request  Block  (SRB),  and  the 
MaximumPhysicalPages,  which  is  the  maximum  number  of  physical  pages  that  a  data  buffer  can 
span. 


The  two  IOCTLs  (IOCTL_SCSI_PASS_THROUGH  and  IOCTL_SCSI_PASS_ 
THROUGH_DIRECT)  allow  SCSI  Command  Descriptor  Blocks  (CDB)  to  be  sent  from  a  Win32 
application  to  a  SCSI  device.  Depending  on  which  IOCTL  is  sent,  a  corresponding  pass  through 
structure  is  fdled  out  by  the  Win32  application. 

The  IOCTL_SCSI_PASS_THROUGH  uses  the  SCSI_PASS_THROUGH  structure.  The 
IOCTL_SCSI_PASS_THROUGH_DIRECT  uses  the  SCSI_PASS_THROUGH_DIRECT 

structure. 

The  SCSI_PASS_THROUGH  structure  is  shown  in  Figure  4-7. 


struct  SCSI_PASS_THROUGH 
{ 

USHORT  Length; 

UCHAR  ScsiStatus; 

UCHAR  Pathld; 

UCHAR  Targetld; 

UCHAR  Lun; 

UCHAR  CdbLength; 

UCHAR  Senselnf oLength; 

UCHAR  Dataln; 

ULONG  DataTransf erLength; 

ULONG  TimeOutValue; 

ULONG  DataBuf ferOf f set; 

ULONG  Senselnf oOff set; 

UCHAR  Cdb [16]; 

} 

Figure  4-7.  SCS I  P ASS  TH ROUGH  structure. 

The  structures  SCSI_PASS_THROUGH  and  SCSI_PASS_THROUGH_DIRECT  are 
virtually  identical.  The  only  difference  is  that  the  data  buffer  for  the  SCSI_PASS_THROUGH 
structure  must  be  contiguous  with  the  structure.  This  structure  member  is  called 
DataBuf  ferOf  f  set  and  is  of  type  ULONG.  The  data  buffer  for  the 

SCSI_PASS_THROUGH_DIRECT  structure  does  not  have  to  be  contiguous  with  the  structure. 
This  structure  member  is  called  DataBuf  fer  and  is  of  type  PVOID. 

For  the  two  SCSI  pass  through  IOCTLs,  IOCTL_SCSI_PASS_THROUGH  and 
IOCTL_SCSI_PASS_THROUGH_DIRECT,  both  lpInBuffer  and  lpOutBuffer  can  vary 
in  size  depending  on  the  Request  Sense  buffer  size  and  the  data  buffer  size.  In  all  cases, 
nlnBuf  ferSize  and  nOutBuf  ferSize  must  be  at  least  the  size  of  the 
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SCSI_PASS_THROUGH  (or  SCSI_PASS_THROUGH_DIRECT)  structure.  Once  the 
appropriate  input  and  output  buffers  have  been  allocated,  then  the  appropriate  structure  must  be 
initialized. 

The  Length  is  the  size  of  the  SCSI_PASS_THROUGH  structure.  The  ScsiStatus 

should  be  initialized  to  0.  The  SCSI  status  of  the  requested  SCSI  operation  is  returned  in  this 
structure  member.  The  Pathld  is  the  bus  number  for  the  SCSI  host  adapter  that  controls  the 
SCSI  device  in  question.  Typically,  this  value  will  be  0,  but  there  are  SCSI  host  adapters  that 
have  more  than  one  SCSI  bus  on  the  adapter.  The  Targetld  and  Lun  are  the  SCSI  ID  number 
and  logical  unit  number  for  the  device. 

The  CdbLength  is  the  length  of  the  CDB.  Typical  values  are  6,  10,  and  12  up  to  the 
maximum  of  16.  The  Senselnf  oLength  is  the  length  of  the  Senselnf  o  buffer.  Dataln 
has  three  possible  values;  SCSI_IOCTL_DATA_OUT,  SCSI_IOCTL_DATA_IN  and 
SCSI_IOCTL_DATA_UNSPECIFIED.  The  DataTransf  erLength  is  the  byte  size  of  the 
data  buffer.  The  TimeOutValue  is  the  length  of  time,  in  seconds,  until  a  time-out  error  should 
occur;  this  can  range  from  0  to  a  maximum  of  30  minutes  (1800  seconds). 

The  DataBuf  f  erOf  f  set  is  the  offset  of  the  data  buffer  from  the  beginning  of  the  pass 
through  structure.  For  the  SCSI_PASS_THROUGH_DIRECT  structure,  this  value  is  not  an 
offset,  but  rather  is  a  pointer  to  a  data  buffer.  The  Senselnf  oOffset  is  similarly  an  offset  to 
the  Senselnfo  buffer  from  the  beginning  of  the  pass  through  structure.  Finally,  the  sixteen 
remaining  bytes  are  for  the  CDB  data.  The  format  of  this  data  must  conform  to  the  SCSI-2 
standard. 

4.3  Standardization  Agreement  (STANAG)  4575  Directory 

Chapter  10  recorders  and  RMMs  make  their  data  available  for  downloading  over  one  of 
their  supported  download  ports.  To  the  application  program,  the  data  download  port  appears  as  a 
block  I/O  disk  device  at  SCSI  LUN  0.  The  directory  structure  on  the  disk  is  a  modified  version 
of  the  STANAG  4575  file  structure  definition.  The  STANAG  file  system  has  been  developed  to 
enable  the  downloading  of  very  large  sequential  files  into  support  workstations.  It  supports  only 
logically  contiguous  files  in  a  single  directory.  The  data  can  be  physically  organized  any  way 
appropriate  to  the  media,  including  multiple  directories,  as  long  as  the  interface  to  the  NATO 
Advanced  Data  Storage  Interface  (NADSI)  “sees”  a  single  directory  of  files  in  contiguous  logical 
addresses. 

Disk  blocks  are  accessed  by  Logical  Block  Address  (LBA).  It  is  common  in  many 
operating  systems  (OSs)  and  disk  structures  for  block  0  to  be  a  Master  Boot  Record  (MBR).  An 
MBR  typically  contains  OS  boot  code  and/or  information  for  dividing  a  disk  device  into  multiple 
partitions.  Chapter  10  does  not  support  MBRs  or  partitions.  Block  0  is  considered  reserved,  and 
its  contents  are  undefined  and  unused. 

The  beginning  of  the  STANAG  directory  is  always  read  from  logical  block  1.  The 
complete  disk  directory  may  span  multiple  disk  blocks.  Directory  blocks  are  organized  as  a 
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double  linked  list  of  blocks.  Other  than  the  first  directory  block,  subsequent  directory  blocks  can 
be  any  arbitrary  block  number. 

A  STANAG  4575  directory  block  has  the  structure  shown  in  Figure  4-8.  IRIG  106-03 
and  IRIG  106-04  defined  the  STANAG  4575  directory  data  as  “little-endian.”  Subsequent  IRIG 
106  versions  have  defined  directory  data  as  “big-endian.”  Applications  can  test  the 
achMagicNumber  and  uRevLink  values  to  determine  whether  big-endian  or  little-endian  is 
being  used.  If  big-endian  is  being  used,  multi-byte  values  will  need  to  be  byte  swapped  before 
they  can  be  used  on  a  little  endian  processor  such  as  an  Intel  x86  found  in  desktop  computers. 
The  various  fields  in  the  directory  block  are  covered  in  detail  in  the  Chapter  10  standard.  The 
asuFileEntry  [  ]  array  holds  information  about  individual  files.  Its  structure  is  shown  in 
Figure  4-9.  The  size  of  the  asuFileEntry  [  ]  array  will  vary  depending  on  the  disk  block 
size.  For  a  size  of  5 12  bytes  per  disk  block,  the  asuFileEntry  [  ]  array  will  have  four 
elements. 


struct  SuStanag4575DirBlock 


{ 

uint8_t 
uint8_t 
uint8_t 
uintl 6_t 
uint32  t 
uint8_t 
uint64_t 
uint64  t 


achMagicNumber [ 
uRevNumber ; 
uShutdown; 
uNumEntries ; 
uBlockSize; 
achVolName [ 32 ] ; 
uFwdLink; 
uRevLink; 


//  "FORTYtwo" 

//  IRIG  106  Revision  number 
//  Dirty  shutdown 
//  Number  of  file  entries 
//  Bytes  per  block 
/ /  Volume  Name 
//  Forward  link  block 
//  Reverse  link  block 


struct  SuStanag4575FileBlock  asuFileEntry [ 4 ]; 
}  ; 


Figure  4-8.  STANAG  4575  Directory  Block  structure. 


struct  SuStanag4575FileBlock 
{ 


uint8  t 

achFileName [56] ; 

// 

File 

name 

uint64  t 

uFileStart; 

// 

File 

start  block  addr 

uint64  t 

uFileBlkCnt; 

// 

File 

block  count 

uint64  t 

uFileSize; 

// 

File 

size  in  bytes 

uint8  t 

uCreateDate  [  8 ] ; 

// 

File 

create  date 

uint8  t 

uCreateTime [ 8 ] ; 

// 

File 

create  time 

uint8  t 

u Time Type; 

// 

Date 

and  time  type 

uint8  t 

achReserved [ 7 ] ; 

// 

uint8  t 

}; 

uCloseTime [ 8 ] ; 

// 

File 

close  time 

Figure  4-9.  STANAG  4575  File  Entry  structure 

A  complete  disk  file  directory  is  read  starting  at  LBA  1 .  The  first  directory  block  is  read 
and  all  file  entries  in  that  block  are  read  and  decoded.  Then  the  next  directory  block,  LBA  equal 
to  the  value  in  uFwdLink,  is  read  and  decoded.  Directory  reading  is  finished  when  the 
uFwdLink  equals  the  current  LBA.  This  algorithm  is  shown  in  Figure  4-10. 
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Figure  4-10.  STANAG  4575  directory  reading  and  decoding  algorithm. 
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CHAPTER  5 

RECORDER  COMMAND  AND  CONTROL 

Recorders  are  controlled  over  a  full  duplex  communications  channel.  Typically,  this 
channel  is  either  a  Recommended  Standard  232  (RS-232)  or  an  RS-422  serial  communications 
port.  Chapter  10  of  IRIG  106  also  defines  a  mechanism  which  allows  control  over  any  of  the 
supported  recorder  network  channels,  including  Ethernet,  Fibre  Channel,  and  IEEE  1394b. 

The  recorder  Command  and  Control  Mnemonic  (CCM)  language  is  defined  in  Chapter  6, 
with  further  requirements  in  Chapter  10.  Interaction  with  a  recorder  is  in  a  command/control 
fashion.  That  is,  an  external  controller  issues  commands  to  a  recorder  over  the  command  and 
control  channel,  and  the  recorder  issues  a  single  status  response  message. 

Some  commands,  such  as  .BIT,  can  take  a  significant  amount  of  time  to  complete.  The 
proper  method  to  determine  when  these  commands  are  complete  is  to  issue  multiple  .  STATUS 
commands,  checking  the  status  complete  field  until  it  indicates  the  command  has  completed 
processing. 

5.1  Serial  Control 

Commands  written  to  a  recorder  should  be  terminated  with  carriage  return  and  line  feed 
characters.  Responses  from  the  recorder  also  terminate  with  carriage  return  and  line  feed.  In 
general,  it’s  considered  good  defensive  programming  practice  to  recognize  either  character  alone 
or  both  together  as  a  valid  line  terminator.  Commands  are  not  case  sensitive. 

Neither  Chapter  6  nor  Chapter  10  addresses  serial  flow  control.  Most  commands 
generate  very  little  text,  and  buffer  overflow  shouldn’t  be  a  problem.  However,  the  .  TMATS 
command  can  result  in  a  considerable  amount  of  text  being  transferred.  Hardware  flow  control 
requires  additional  signal  lines  that  may  not  be  available  on  a  recorder  command  and  control 
interface.  It  would  be  prudent  to  be  prepared  to  support  XON  and  XOFF  flow  control  in  software. 

5.2  Network  Control 

Chapter  10  provides  a  mechanism  for  remote  command  and  control  over  a  network  port 
using  the  SCSI  protocol.  Chapter  10  defines  separate  Logical  Units  for  command  and  control. 
The  SCSI  “SEND”  command  (command  code  =  OxOA)  along  with  a  buffer  containing  a  valid 
Chapter  6  command  is  used  to  send  commands  remotely.  The  SCSI  “RECEIVE”  command 
(command  code  =  0x08)  is  used  to  receive  the  command  response.  These  SCSI  command  are 
described  in  the  SCSI  Primary  Commands  document  in  paragraph  2.2h. 
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CHAPTER  6 

DATA  FILE  INTERPRETATION 
6.1  Overall  Data  File  Organization 

Chapter  10  data  files  are  organized  as  a  sequential  series  of  data  packets.  Each  data 
packet  can  only  contain  one  type  of  data  (i.e.  1553,  Pulse  Code  Modulation  (PCM),  etc.).  Data 
packets  frequently  contain  multiple  individual  data  messages. 

The  Chapter  10  standard  requires  that  the  first  data  packet  in  a  data  file  be  an  IRIG  106 
Chapter  9  format,  Telemetry  Attributes  Transfer  Standard  (TMATS)  packet.  The  TMATS 
packet  is  used  to  configure  the  recorder  and  to  describe  the  data  being  recorded.  Also,  TMATS 
is  stored  in  a  Computer  Generated  Data,  Format  1  (Data  Type  =  0x01)  data  packet  and  is 
discussed  in  paragraph  6.5.2. 

An  important  field  in  the  packet  header  for  the  TMATS  packet  is  the  "IRIG  106 
Chapter  10  Version"  field.  The  value  of  this  field  determines  the  specific  version  of  the 
Chapter  10  standard  to  use  when  interpreting  the  rest  of  the  data  file.  This  value  should  not  be 
confused  with  the  Data  Type  Version  (but  sometimes  called  Header  Version)  discussed  in 
paragraph  6.3.  The  IRIG  106  Version  field  is  only  defined  for  the  IRIG  106-07  and  later 
versions  of  the  IRIG  106  standard.  Since  unused  reserved  fields  must  be  initialized  to  zero,  this 
field  will  have  a  value  of  0  in  data  files  compliant  with  IRIG  106  prior  to  IRIG  106-07. 

Starting  with  publication  of  IRIG  106-07,  more  than  one  TMATS  packet  is  allowed  at  the 
beginning  of  the  file  if  recorder  configuration  information  exceeds  the  packet  size  limit. 

It  is  required  that  a  Time  Data  packet  be  the  first  "dynamic"  data  packet.  Dynamic  data 
packets  are  not  defined  in  the  Chapter  10  standard  but  it  is  generally  understood  that  a  dynamic 
data  packet  means  any  data  packet  other  than  Computer  Generated  Data  Format  1  (setup  record). 
The  purpose  of  this  requirement  is  to  allow  the  association  of  clock  time  with  the  Relative  Time 
Counter  (RTC)  before  encountering  the  first  data  packet  in  the  data  file.  Programmers  are 
cautioned  to  verify  a  valid  time  packet  has  been  received  before  attempting  to  interpret  the  RTC 
as  described  in  paragraph  6.6. 

A  root  index  packet  will  be  the  last  data  packet  in  the  data  file  if  file  indexing  is  used. 

The  presence  of  data  file  indexing  is  indicated  in  the  TMATS  setup  record. 

The  size  of  all  data  packets  is  an  integer  multiple  of  4  bytes  (32  bits)  with  the  maximum 
size  of  524,288  bytes.  Computer  Generated  Data,  Fonnat  1  (TMATS)  packets  have  a  maximum 
packet  size  of  134,217,728  bytes.  To  provide  this  4  byte  alignment,  padding  bytes  are  added,  if 
necessary,  to  the  end  of  a  data  packet,  just  before  the  checksum.  Regardless,  when  defining  data 
structures  representing  Chapter  10  data  packets  and  messages,  these  structures  should  be  forced 
to  be  byte  aligned  by  using  the  appropriate  compiler  directive. 
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Some  data  packet  elements  are  two  or  more  bytes  in  length.  For  example,  the  first  data 
element  of  a  data  packet  is  a  two  byte  sync  pattern.  Multiple  byte  data  elements  are  stored  in 
little  endian  format.  That  is,  the  least  significant  portion  of  the  data  is  stored  at  the  lowest  byte 
offset. 


Data  packets  are  written  to  disk  roughly  in  the  time  order  in  which  they  are  received,  but 
data  packets  and  data  messages  can  occur  in  the  data  file  out  of  time  order.  This  order  can  occur 
because  data  recorders  receive  data  simultaneously  on  multiple  channels,  each  channel  buffering 
data  for  a  period  of  time  and  then  writing  it  to  disk.  Therefore,  individual  data  messages  will,  in 
general,  be  somewhat  out  of  time  order  because  of  grouping  by  channel.  Consider  the  case  of 
two  1553  channels  recording  the  same  bus  at  the  same  time  in  an  identical  fashion.  Each  channel 
receives,  buffers,  and  writes  data  to  disk.  The  first  channel  will  write  its  buffered  data  to  disk 
followed  by  the  second  channel.  The  data  received  from  the  second  channel  will  be  from  the 
same  time  period  as  the  data  from  the  first  channel  and  will  have  identical  time  stamps  but  will 
be  recorded  after  the  first  channel  in  the  data  file. 

Starting  with  the  IRIG  106-05  standard,  recorders  are  only  allowed  to  buffer  data  for  a 
maximum  of  100  milliseconds  and  data  packets  must  be  written  to  disk  within  one  second.  This 
ensures  that  data  packets  can  only  be  out  of  time  order  by  a  maximum  of  one  second.  Be 
warned,  though,  that  the  maximum  amount  of  time  data  packets  can  be  out  of  order  for  data  files 
produced  before  IRIG  106-05  is  unbounded  and  it  is  not  unusual  to  encounter  data  files  with  data 
packets  five  or  more  seconds  out  of  time  order. 

Example  source  code  that  demonstrates  basic  parsing  of  Chapter  10  data  files  can  be 
found  in  Appendix  A.  An  example  program  that  demonstrates  reading  and  interpreting  a 
Chapter  10  file  can  be  found  in  Appendix  B. 

6.2  Overall  Data  Packet  Organization 

Overall  data  packet  organization  is  shown  in  Figure  6G .  Data  packets  contain  a  standard 
header,  a  data  payload  containing  one  or  multiple  data  messages,  and  a  standard  trailer.  The 
standard  header  is  composed  of  a  required  header,  optionally  followed  by  a  secondary  header. 
The  data  payload  generally  consists  of  a  Channel  Specific  Data  Word  (CSDW)  record  followed 
by  one  or  more  data  messages. 
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PACKET  SYNC  PATTERN 

Packet  Header 

CHANNEL  ID 

PACKET  LENGTH 

DATA  LENGTH 

DATA  VERSION 

SEQUENCE  NUMBER 

PACKET  FLAGS 

DATA  TYPE 

RELATIVE  TIME  COUNTER 

HEADER  CHECKSUM 

TIME 

Packet 

Secondary  Header 
(Optional) 

RESERVED 

SECONDARY  HEADER  CHECKSUM 

CHANNEL  SPECIFIC  DATA  WORD 

Packet  Body 

INTRA-PACKET  TIME  STAMP  1 

INTRA-PACKET  DATA  HEADER  1 

DATA  1 

INTRA-PACKET  TIME  STAMP  n 

INTRA-PACKET  DATA  HEADER  n 

DATAn 

DATA  CHECKSUM 

Packet  Trailer 

Figure  6- 1 .  Data  packet  organization. 


Data  packets  must  contain  data.  They  are  not  allowed  to  only  contain  filler.  Filler  can  be 
inserted  into  a  data  packet  in  the  packet  trailer  before  the  checksum.  This  filler  is  used  to  ensure 
data  packet  alignment  on  a  four  byte  boundary.  Filler  is  also  sometimes  used  to  keep  the  same 
length  of  packets  from  a  particular  channel.  The  standard  does  not  expressly  prohibit  filler  after 
the  packet  trailer  but  before  the  next  data  packet  header;  however,  inserting  filler  after  the  last 
trailer  is  considered  bad  practice.  Still,  when  reading  data  packets,  the  programmer  should  set 
read  buffer  sizes  based  on  the  value  of  the  overall  packet  length  found  in  the  header.  Do  not 
make  assumptions  about  packet  length  based  on  the  data  length  or  from  information  in  the  data 
payload. 

When  reading  linearly  through  a  Chapter  10  data  file,  maintaining  synchronization  with 
data  packet  boundaries  is  accomplished  by  using  the  packet  length  field  in  the  header  to  read  the 
appropriate  amount  of  data  or  to  reposition  the  read  pointer  to  the  beginning  of  the  next  header. 
In  this  case,  it  is  sufficient  to  check  the  value  of  the  Sync  field  at  the  beginning  of  the  header  to 
ensure  the  read  pointer  was  positioned  to  the  beginning  of  a  data  packet. 

If  there  is  an  error  in  the  data  file,  or  if  the  read  pointer  is  repositioned  to  a  position  other 
than  the  beginning  of  a  data  packet  (for  example  to  jump  to  the  middle  of  a  recorded  data  file), 
then  the  beginning  of  a  valid  data  packet  must  be  found.  Unfortunately  the  Chapter  10  standard 
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does  not  provide  a  way  to  definitively  determine  the  beginning  of  a  data  packet  in  these 
instances.  Instead,  some  heuristics  must  be  applied: 


a.  Read  the  data  file  until  the  packet  sync  pattern  (0xEB25)  is  found.  Normally  the  first 
character  of  the  packet  sync  pattern  is  found  at  a  file  offset  which  is  an  integer 
multiple  of  four.  However,  if  the  data  file  is  corrupted  then  the  sync  pattern  may  not 
fall  on  the  normal  four  byte  boundary.  Scan  the  file  a  byte  at  a  time,  ignoring  the 
normal  four  byte  alignment.  When  the  Sync  pattern  is  found  then 

b.  Calculate  and  test  the  header  checksum. 

c.  If  a  secondary  header  exists,  calculate  and  test  the  secondary  header  checksum. 

d.  Calculate  and  test  the  data  checksum. 


If  the  packet  sync  pattern  is  found  and  all  available  checksums  have  been  verified,  then 
there  is  a  high  probability  that  the  beginning  of  the  next  valid  data  packet  has  been  found. 

6.3  Required  Header 

The  packet  header  contains  information  about  the  data  payload  such  as  time,  packet 
length,  data  type,  data  version,  and  other  information.  The  layout  of  a  Chapter  10  packet  header 
is  shown  in  Figure  6-2. 


struct  SuI106Chl0Header 
{ 


uintl6  t 

uSync; 

// 

Packet  Sync  Pattern 

uintl6  t 

uChID; 

// 

Channel  ID 

uint32  t 

ulPacketLen; 

// 

Total  packet  length 

uint32  t 

ulDataLen; 

// 

Data  length 

uint8  t 

ubyDataVer ; 

// 

Data  Version 

uint8  t 

ubySeqNum; 

// 

Sequence  Number 

uint8  t 

uby Packet Flags ; 

// 

Packet  Flags 

uint8  t 

ubyDataType; 

// 

Data  type 

uint8  t 

aubyRelTime [ 6 ] ; 

// 

Reference  time 

uintl6  t 
} ; 

uChecksum; 

// 

Header  Checksum 

Figure  6-2. 

Packet  header  structure. 

The  Channel  ID  field  uniquely  identifies  the  source  of  the  data.  The  value  of  the 
Channel  ID  field  corresponds  to  the  Track  Number  value  of  the  TMATS  "R"  record, 

“R-m\TKl .  ”  The  Channel  ID  field  is  a  16-bit  field.  However,  the  Chapter  9  TMATS  format 
restricts  the  value  of  Channel  ID  to  a  two  digit  number  (i.e.  from  0  to  99).  It  is  anticipated  that 
this  TMATS  restriction  will  be  lifted  in  future  IRIG  106  standard  releases. 

Typically,  only  one  packet  data  type  is  associated  with  a  particular  Channel  ID,  but  this  is 
not  a  requirement  of  the  Chapter  10  standard.  An  exception  to  this  is  Channel  ID  =  0,  the 
Channel  ID  used  for  internal,  computer  generated  format  data  packets.  It  is  typical  for  Channel 
ID  0  to  contain  Computer  Generated  Data  Format  1  Setup  Records  (0x01),  Computer  Generated 
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Data  Format  2  Recording  Events  Records  (0x02),  and  Computer  Generated  Data  Format  3 
Recording  Index  Records  (0x03). 

The  data  payload  format  is  interpreted  based  on  the  value  of  the  Data  Type  field  and  the 
Data  Version  field  in  the  packet  header.  This  field  is  sometimes  incorrectly  called  “Header 
Version.”  Each  packet  data  payload  can  only  contain  one  type  of  data  (e.g.  1553,  PCM,  etc.).  A 
Chapter  10  standard  release  will  only  contain  data  format  and  layout  information  for  the  latest 
Data  Version.  The  specific  Data  Version  defined  in  a  particular  Chapter  10  release  can  be  found 
in  the  "Data  Type  Names  and  Descriptions"  table.  Be  warned  that  future  Chapter  10  releases 
may  update  or  change  data  format  or  layout,  indicated  by  a  different  Data  Version  value  in  the 
header,  but  the  Chapter  10  release  will  not  have  information  about  the  previous  Data  Versions. 
That  information  can  only  be  found  in  the  previous  Chapter  10  releases. 

When  processing  a  data  file,  it  is  common  to  only  read  the  data  packet  header,  detennine 
if  the  data  portion  is  to  be  read  (based  on  packet  type  or  other  information  gleaned  from  the 
header),  and,  if  not  to  be  read,  skip  ahead  to  the  next  header.  Skipping  the  data  portion  and 
jumping  ahead  to  the  next  header  is  accomplished  by  using  the  packet  length  in  the  packet 
header.  Below  is  the  algorithm  for  determining  how  many  bytes  to  jump  ahead  in  the  file  byte 
stream  to  reposition  the  read  pointer  to  the  beginning  of  the  next  header: 

a.  Read  the  current  primary  header 

b.  Determine  relative  file  offset  to  the  next  header 

Offset  =  Packet  Length 

-  Primary  Header  Length  (24) 

-  Secondary  Header  Length  (12)  (if  included) 

c.  Move  read  pointer 

6.4  Optional  Secondary  Header 

The  optional  secondary  header  is  used  to  provide  an  absolute  time  (i.e.  clock  time)  stamp 
for  data  packets.  The  secondary  header  time  format  can  be  interpreted  several  ways.  The 
specific  interpretation  is  determined  by  the  value  of  header  Flag  Bits  2  and  3.  The  structure  in 
Figure  6-3  is  used  when  secondary  header  time  is  to  be  interpreted  as  a  Chapter  4  fonnat  value 
(Flag  Bits  3-2  =  0).  The  structure  in  Figure  04  is  used  when  secondary  header  time  is  to  be 
interpreted  as  an  IEEE  1588  format  value  (Flag  Bits  3-2  =  1). 


struct  Sul 1 0  6ChlOSecHeader_Ch4 Time 
( 


uintl 6 

t 

uUnused; 

// 

uintl 6 

t 

uHighBinTime; 

// 

High  order  time 

uintl 6 

t 

uLowBinTime; 

// 

Low  order  time 

uintl 6 

t 

uUSecs ; 

// 

Microsecond  time 

uintl 6 

t 

uReserved; 

// 

uintl 6 

}; 

t 

uSecChecksum; 

// 

Secondary  Header  Checksum 

Figure  6-3.  Optional  secondary  header  structure  with  IRIG  106  Ch  4  time  representation. 
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struct  SuI106Chl0SecHeader_1588Time 
{ 


uint32 

t 

uNanoSeconds ; 

// 

Nano-seconds 

uint32 

t 

uSeconds ; 

// 

Seconds 

uintl 6 

t 

uReserved; 

// 

uintl 6 

t 

uSecChecksum; 

// 

Secondary  Header  Checksum 

}  ; 

Figure  6-4.  Optional  secondary  header  structure  with  IEEE  1588  time  representation. 

6.5  Data  Payload 

After  the  standard  header  and  optional  secondary  header,  each  data  packet  begins  with 
CSDW(s).  The  length  of  the  CSDW  varies  depending  on  the  data  type.  For  example,  Analog 
Data  Format  1  may  have  multiple  CSDWs.  The  CSDW  provides  information  necessary  to 
decode  the  data  messages  that  follow.  For  example,  it  is  common  for  the  CSDW  to  contain  a 
value  for  the  number  of  messages  that  follow  and  to  have  flags  that  indicate  what  kind  of  intra¬ 
packet  headers  are  used  between  messages. 

Reading  and  decoding  a  data  packet  is  accomplished  by  first  reading  the  CSDW.  Then 
individual  data  messages  that  follow  in  the  data  packet  are  read,  taking  into  account  the 
appropriate  intra-packet  headers  and  data  formats.  Move  on  to  the  next  header  and  data  packet 
when  there  are  no  more  data  messages  to  read. 

Intra-packet  headers,  when  they  are  present,  typically  contain  one,  or  sometimes  more 
than  one,  time  stamp  as  well  as  other  information  about  the  data  message  that  follows. 
Commonly  used  structures  for  intra-packet  time  data  are  shown  in  Figure  6-5,  Figure  6-6,  and 
Figure  6-7.  These  three  time  structures  will  be  referenced  in  most  of  the  data  format  descriptions 
that  follow. 


struct  SuIntrPacketTime  RTC 
{ 

uint8_t  aubyRelTime [ 6 ] ;  //  48  bit  RTC 

uintl6_t  uUnused;  // 

}  ; 


Figure  6-5.  Intra-packet  Time  Stamp,  48-bit  RTC. 


struct  SuIntrPacketTime  Ch4Time 
{ 


uintl 6 

t 

uUnused; 

// 

uintl 6 

t 

uHighBinTime; 

// 

High  order  time 

uintl 6 

t 

uLowBinTime; 

// 

Low  order  time 

uintl 6 

}; 

t 

uUSecs ; 

// 

Microsecond  time 

Figure  6-6.  Intra-packet  Time  Stamp,  IRIG  106  Ch  4  binary. 
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struct  SuIntrPacketTime  1588Time 
{ 

uint32_t  uNanoSeconds ;  //  Nano-seconds 

uint32_t  uSeconds;  //  Seconds 

}  ; 


Figure  6-7.  Intra-packet  Time  Stamp,  IEEE  1588. 

6.5.1  Type  0x00,  Computer  Generated  Data,  Format  0.  Computer  Generated  Data,  Format  0 
packets  are  used  to  store  data  generated  internally  by  a  recorder.  The  data  packet  begins  with  the 
CSDW  shown  in  Figure  6-8.  The  data  portion  of  the  data  packet  is  undefined  and  left  to  the 
discretion  of  the  recorder  manufacturer. 


struct  SuCompGenO_ChanSpec 
{ 

uint32_t  uReserved; 

}  ; 


Figure  6-8.  Type  0x00  Computer  Generated  Data  Format  0  (User)  CSDW. 

6.5.2  Type  0x01,  Computer  Generated  Data,  Format  1  (Setup  Record).  Computer  Generated 
Data,  Format  1  packets  are  used  to  store  the  TMATS  recorder  configuration  record.  The  data 
packet  begins  with  the  CSDW  shown  in  Figure  6-9. 


struct  SuTmats  ChanSpec 
{ 

uint32  t  iChlOVer 

:  8; 

// 

Recorder 

Ch  10  Version 

uint32  t  bConf igChange 

:  1; 

// 

Recorder 

config  changed 

uint32  t  iReserved 

} ; 

:  23; 

// 

Reserved 

Figure  6-9.  Type  0x01  Computer  Generated  Data  Format  1  (Setup)  CSDW. 


Note  that  this  structure  definition  for  the  CSDW  first  appeared  in  IRIG  106-07.  Since 
unused  fields  are  required  to  be  zero  filled,  data  files  prior  to  IRIG  106-07  will  have  a  value  of 
zero  in  the  iChlOVer  field. 

The  first  data  packet  in  a  Chapter  10  data  file  must  be  a  TMATS  setup  record.  Under 
certain  conditions,  TMATS  setup  records  may  also  be  found  later  in  the  same  recorded  data  file. 
In  particular,  subsequent  TMATS  records  may  occur  during  network  data  streaming  of 
Chapter  10  data  to  allow  network  data  users  to  learn  the  recorder  configuration  after  recording 
and  streaming  has  begun.  The  bConf  igChanged  flag  is  used  to  indicate  whether  this  TMATS 
setup  record  is  different  than  the  previous  TMATS  setup  record  (i.e.  the  recorder  configuration 
changed)  or  whether  it  duplicates  the  previous  TMATS  setup  record. 

During  analysis  of  previously  recorded  data,  it  is  useful  to  be  able  to  quickly  locate 
TMATS  setup  records,  especially  setup  records  that  are  different  from  previous  setup  records  in 
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the  data  file.  The  preferred  method  to  locate  these  setup  records  is  by  indexing  Computer 
Generated  Data  Format  1  packets  using  the  indexing  method  described  in  paragraph  6.7. 

The  data  that  follows  the  CSDW  in  the  data  packet  is  the  TMATS  setup  information  in 
Chapter  9  format. 

6.5.3  Type  0x02,  Computer  Generated  Data,  Format  2  (Recording  Events).  Computer 
Generated  Data,  Format  2  packets  are  used  to  record  the  occurrence  of  events  during  a  recording 
session.  Event  criteria  are  defined  in  the  TMATS  setup  record.  Note  that  a  recorded  event  is 
different  and  distinct  from  a  Chapter  6  .EVENT  command.  A  .EVENT  command  may  result  in  a 
Recording  Event  packet  if  it  has  been  defined  in  the  TMATS  setup  record. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-10.  The  uEventCount  field  is  a  count 
of  the  total  number  of  events  in  this  packet.  The  blntraPckHdr  field  indicates  the  presence 
of  the  optional  intra-packet  data  header  in  the  intra-packet  header. 


struct  SuEvents_ChanSpec 
{ 


uint32 

uint32 

t 

t 

uEventCount 

uReserved 

:  12; 

:  19; 

// 

Total  number 

of  events 

uint32 

t 

blntraPckHdr 

:  1; 

// 

Intra-packet 

header  present 

}  ; 

Figure  6-10.  Type  0x02  Computer  Generated  Data  Format  2  (Events)  CSDW. 

There  are  a  number  of  pennutations  of  the  recorded  event.  In  fact,  there  are  enough 
permutations  that  it  makes  sense  to  represent  the  data  message  layout  in  non-specific  terms. 
Later,  during  packet  processing,  generic  data  fields  can  be  cast  to  their  specific  formats.  Event 
data  without  optional  data  (blntraPckHdr  =  0)  is  shown  in  Figure  6-11.  Event  data  with 
optional  data  (blntraPckHdr  =  1)  is  shown  in  Figure  6-12.  The  format  for  the  event 
message  itself  is  shown  in  Figure  6-13. 


struct  SuEvents 

{ 

uint64  t 

suIntraPckTime; 

// 

Intra-packet  time  stamp 

struct  SuEvents  Data 

}; 

suData; 

// 

Data  about  the  event 

Figure  6-11.  Type  0x02  Computer  Generated  Data  Format  2  (Events)  message  without 


optional  data. 
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struct  SuEvents  with 

{ 

uint64  t 

Optional 

suIntraPckTime; 

// 

Intra-packet  time  stamp 

uint64  t 

suIntrPckData; 

// 

Intra-packet  data 

struct  SuEvents 

}; 

Data  suData; 

// 

Data  about  the  event 

Figure  6-12.  Type  0x02  Computer  Generated  Data  Format  2  (Events)  message  with 
optional  data 


struct  SuEvents 

{ 

uint32  t 

Data 

uNumber 

12; 

// 

Event 

identification  number 

uint32  t 

uCount 

16; 

// 

Event 

count  index 

uint32  t 

bEventOccurence 

1; 

// 

uint32  t 

} ; 

uReserved 

3; 

// 

Figure  6-13.  Type  0x02  Computer  Generated  Data  Format  2  (Events)  message  data. 


The  suIntraPckTime  field  in  the  data  structures  of  Figure  6-11  and  Figure  6-12 
(shown  above)  represents  event  time  in  either  48-bit  relative  time  format  derived  from  the  RTC 
(format  shown  in  Figure  6-5),  or  as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either 
Chapter  4  weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time  format  (format 
shown  in  Figure  6-7). 

If  the  event  message  includes  the  optional  suIntrPckData  Intra-packet  Data  Header 
field,  shown  in  the  data  structure  of  Figure  6-12,  this  field  holds  the  absolute  time  of  the  event. 
The  format  of  this  data  is  the  same  as  the  Time  Data  Packet  Format  1,  depicted  in  Figure  6-18 
and  Figure  6-19.  Unfortunately,  Time  Data  Packet  Format  1  represents  time  in  more  than  one 
format  and  this  data  format  does  not  include  a  method  to  determine  which  time  format  is  used  in 
the  Intra-packet  Data  Header.  For  this  reason,  this  field  should  be  used  with  caution,  if  used  at 
all.  Data  about  the  recorded  event  is  found  in  the  SuEvents_Data  structure  shown  in 
Figure  6-13.  The  particular  event  is  identified  by  the  uNumber  field,  which  corresponds  to 
Recording  Event  index  number  (i.e.  the  "n"  value  in  "R-x\EV\  ID-n")  in  the  TMATS  Setup 
Record  for  this  recording.  The  uCount  field  is  incremented  each  time  this  event  occurs.  The 
bEventOccurence  field  indicates  whether  the  event  occurred  during  or  between  record 
enable  commands. 

6.5.4  Type  0x03,  Computer  Generated  Data,  Format  3  (Recording  Index).  Computer 
Generated  Data,  Format  3  packets  record  file  offset  values  that  point  to  various  important  data 
packets  in  the  recording  data  file.  Chapter  10  data  files  can  be  very  large,  and  it's  generally 
impractical  to  search  for  specific  data  without  an  index  of  some  sort.  Currently  recording  index 
packets  are  used  to  index  the  position  of  time  packets  and  event  packets  to  make  it  easy  to  move 
to  a  specific  time  or  event  in  the  data  file.  However,  nothing  precludes  the  use  of  index  packets 
to  index  other  data  packet  types. 


6-9 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


Index  entries  are  organized  into  a  two  tier  tree  structure  of  Root  Index  packets  and  Node 
Index  packets.  A  Node  Index  Entry  contains  information  (e.g.  packet  type,  channel,  offset) 
about  the  specific  data  packet  to  which  it  points.  Multiple  Index  Entries  are  contained  in  a  Node 
Index  type  of  index  packet.  A  Root  Index  type  of  index  packet  is  used  to  point  to  Node  Index 
packets  in  the  data  file.  Root  Index  packets  are  organized  as  a  linked  list  of  packets.  Each  Root 
Index  packet  contains  a  value  for  the  file  offset  of  the  preceding  Root  Index  packet  in  the  linked 
list.  Index  packets  (Root  and  Node)  can  be  stored  anywhere  in  a  data  file  with  the  exception  that 
the  final  Root  Index  packet  must  be  the  last  data  packet  in  a  data  file.  The  presence  of  indexing 
is  also  indicated  by  the  TMATS  field  "R-x\IDX\E"  having  a  value  of  "T"  (i.e.  "true").  Note 
that  it  is  currently  not  unusual  to  find  a  TMATS  IDX  value  of  false,  but  find  a  valid  Root  Node 
packet  at  the  end  of  the  data  file. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-14,  and  is  a  common  format  between  Root 
and  Node  index  packets.  The  uldxEntCount  field  is  a  count  of  the  total  number  of  indexes  in 
this  packet.  The  blntraPckHdr  field  indicates  the  presence  of  the  optional  intra-packet  data 
header.  The  bFileSize  field  indicates  the  presence  of  the  optional  file  size  field.  The 
ulndexType  field  indicates  the  whether  the  indexes  that  follow  are  Root  or  Node  indexes.  If 
file  size  is  present,  it  follows  the  CSDW  as  an  unsigned  64-bit  value. 


struct  Sulndex 

{ 

uint32  t 

ChanSpec 

uldxEntCount 

16; 

// 

Total  number 

of  indexes 

uint32  t 

uReserved 

13; 

uint32  t 

blntraPckHdr 

1; 

// 

Intra-packet 

header  present 

uint32  t 

bFileSize 

1; 

// 

File  size  present 

uint32  t 

}; 

ulndexType 

1; 

// 

Index  type 

Figure  6-14.  Type  0x03  Computer  Generated  Data  Format  3  (Index)  CSDW 


Node  Index  packets  are  composed  of  a  CSDW,  an  optional  file  size  field,  and  multiple 
Node  Index  structures. 

Each  Node  Index  structure  is  composed  of  an  intra-packet  time  stamp,  an  optional  intra¬ 
packet  data  header,  and  a  Node  Index  Entry  data  structure.  The  intra-packet  time  stamp 
represents  indexed  packet  data  time  in  either  48-bit  relative  time  format  derived  from  the  RTC 
(format  shown  in  Figure  6-5)  ,  or  as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either 
Chapter  4  weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time  format  (format 
shown  in  Figure  6-7). 

If  the  index  message  includes  the  optional  Intra-packet  Data  Header  field,  this  field  holds 
the  absolute  time  of  the  Index.  The  format  of  this  data  is  the  same  as  the  Time  Data  Packet 
Format  1,  depicted  in  Figure  6-18  and  Figure  6-19.  Unfortunately,  Time  Data  Packet  Fonnat  1 
represents  time  in  more  than  one  format  and  this  data  format  does  not  include  a  method  to 
determine  which  time  format  is  used  in  the  Intra-packet  Data  Header.  For  this  reason,  this  field 
should  be  used  with  caution,  if  used  at  all. 
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The  structure  of  the  Node  Index  Entry  is  shown  in  Figure  6-15.  The  uChannellD  field 
is  the  Channel  ID  of  the  indexed  data  packet.  The  uDataType  field  is  the  data  type  of  the 
indexed  data  packet.  The  uOf  f  set  field  is  an  unsigned  eight  byte  value  representing  the  offset 
from  the  beginning  of  the  data  file  to  the  indexed  data  packet.  The  uOf  f  set  field  should 
always  point  to  the  Sync  Pattern  (0xEB25)  of  the  indexed  data  packet. 


struct  Sulndex 

{ 

uint32  t 

Data 

uChannellD 

:  16; 

uint32  t 

uDataType 

:  8; 

uint32  t 

uReserved 

:  8; 

uint64  t 

}; 

uOf f set; 

Figure  6-15.  Type  0x03  Computer  Generated  Data  Format  3  (Index)  Node  Index  Entry. 


Root  Index  packets  are  composed  of  a  CSDW,  an  optional  file  size  field,  and  multiple 
Root  Index  Entry  structures.  Root  Index  structures  provide  information  about  and  point  to  Node 
Index  packets  described  above. 

Each  Root  Index  is  composed  of  an  intra-packet  time  stamp,  an  optional  intra-packet  data 
header,  and  a  Node  Index  data  packet  offset  value.  The  intra-packet  time  stamp  represents 
indexed  packet  data  time  in  either  48-bit  relative  time  format  derived  from  the  RTC  (format 
shown  in  Figure  6-5),  or  as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either  Chapter  4 
weighted  48-bit  time  (format  shown  in  Figure  6^6  or  IEEE  1588  time  format  (format  shown  in 
Figure  6-7). 

If  the  Root  Index  message  includes  the  optional  Intra-packet  Data  Header  field,  this  field 
holds  the  absolute  time  of  the  Node  Index  packet.  The  format  of  this  data  is  the  same  as  the 
Time  Data  Packet  Fonnat  1,  depicted  in  Figure  6-18  and  Figure  6-19.  Unfortunately,  Time  Data 
Packet  Format  1  represents  time  in  more  than  one  format  and  this  data  fonnat  does  not  include  a 
method  to  determine  which  time  format  is  used  in  the  Intra-packet  Data  Header.  For  this  reason, 
this  field  should  be  used  with  caution,  if  used  at  all. 

The  Node  Index  offset  field  of  the  Root  Index  packet  is  an  eight  byte  unsigned  value 
representing  the  offset  from  the  beginning  of  the  data  file  to  the  Node  Index  packet. 

6.5.5  Type  0x04  -  0x07,  Computer  Generated  Data,  Format  4  -  Format  7.  Reserved  for  future 
use. 

6.5.6  Type  0x08,  PCM  Data,  Format  0.  Reserved  for  future  use. 

6.5.7  Type  0x09,  PCM  Data,  Format  1  (IRIG  106  Chapter  4/8).  PCM  Data,  Format  1  packets 
are  used  to  record  Pulse  Code  Modulation  (PCM)  data  frames.  PCM  data  is  a  serial  stream  of 
bits  from  multiple  interleaved  data  sources.  Each  data  source  generally  operates  at  a  different 
data  rate  and  have  their  digital  data  interleaved  in  a  fixed,  defined  fashion.  The  data  from  these 
multiplexed  data  sources  are  organized  into  major  frames  and  minor  frames.  PCM  Data 
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Format  1  records  minor  frames  as  integral  units  of  data.  In  general,  the  PCM  data  packet  will 
contain  multiple  PCM  minor  frame  data  messages  in  packed  and  unpacked  mode.  There  is 
extensive  discussion  of  PCM  in  IRIG  106  Chapter  4,  Chapter  8,  and  Appendix  C,  as  well  as  RCC 
Document  1 19  (Telemetry  Applications  Flandbook). 

The  PCM  minor  frame  data  is  recorded  in  one  of  three  major  modes;  Unpacked  Mode, 
Packed  Mode,  and  Throughput  Mode.  In  Unpacked  Mode,  packing  is  disabled  and  each  data 
word  is  padded  with  the  number  of  filler  bits  necessary  to  align  the  first  bit  of  each  word  with  the 
next  16-bit  boundary  in  16-bit  alignment  mode,  or  the  next  32-bit  boundary  in  32-bit  boundary 
mode.  In  Packed  Mode,  packing  is  enabled  and  padding  is  not  added  to  each  data  word. 
However,  filler  bits  may  be  required  to  maintain  minor  frame  alignment  on  word  boundaries.  In 
Throughput  Mode,  the  PCM  data  are  not  frame  synchronized  so  the  first  data  bit  in  the  packet 
can  be  any  bit  in  the  major  frame.  Chapter  10  discusses  these  modes  in  greater  detail. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-16.  The  uSyncOf  f  set  field  is  the  value 
of  the  byte  offset  into  a  major  frame  for  the  first  data  word  in  a  packet,  and  is  only  valid  in 
Packed  Mode.  The  bUnpackedMode,  bPackedMode,  and  bThruMode  flags  indicate 
Unpacked  Mode,  Packed  Mode,  and  Throughput  Mode  respectively  and  are  mutually  exclusive. 
The  bAlignment  flag  indicates  16  or  32-bit  alignment  of  minor  frames  and  minor  frame  fields. 
The  uMa  jorFrStatus  field  indicates  the  lock  status  of  the  major  frame.  The 
uMinorFrStatus  indicates  the  lock  status  of  the  minor  frame.  The  bMinorFrlnd  flag 
indicates  the  first  word  of  the  packet  is  the  beginning  of  a  minor  frame.  The  bMajorFrlnd 
flag  indicates  the  first  word  of  the  packet  is  the  beginning  of  a  major  frame.  The 
blntraPckHdr  flag  indicates  the  presence  of  intra-packet  headers. 


struct  SuPcmFl 

{ 

uint32  t 

ChanSpec 

uSyncOf f set 

18; 

// 

Sync  offset 

uint32  t 

bUnpackedMode 

1; 

// 

Packed  mode  flag 

uint32  t 

bPackedMode 

1; 

// 

Unpacked  mode  flag 

uint32  t 

bThruMode 

1; 

// 

Throughput  mode  flag 

uint32  t 

bAlignment 

1; 

// 

16/32-bit  alignment  flag 

uint32  t 

Reservedl 

2; 

// 

uint32  t 

uMa j orFrStatus 

2; 

// 

Major  frame  lock  status 

uint32  t 

uMinorFrStatus 

2; 

// 

Minor  frame  lock  status 

uint32  t 

bMinorFrlnd 

1; 

// 

Minor  frame  indicator 

uint32  t 

bMa j  orFrlnd 

1; 

// 

Major  frame  indicator 

uint32  t 

blntraPckHdr 

1; 

// 

Intra-packet  header  flag 

uint32  t 

} 

Reserved2 

1; 

// 

Figure  6-16.  Type  0x09  PCM  Data  Format  1  CSDW. 


The  optional  intra-packet  header  and  individual  PCM  minor  frame  messages  follow  the 
CSDW.  The  format  of  the  intra-packet  data  header  is  shown  in  Figure  6-17.  The 
suIntrPckTime  value  is  an  eight  byte  representation  of  time  in  either  48-bit  relative  time 
format  derived  from  the  RTC  (format  shown  in  Figure  6-5),  or  as  absolute  time.  If  this  time  is 
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absolute  time,  it  is  in  either  Chapter  4  weighted  48-bit  time  (fonnat  shown  in  Figure  6-6)  or 
IEEE  1588  time  format  (format  shown  in  Figure  6-7). 

The  intra-packet  header,  indicated  by  blntraPckHdr  =  1,  is  required  for  unpacked 
and  packed  mode.  It  is  prohibited  for  throughput  mode.  The  uMa  jorFrStatus  field 
indicates  the  lock  status  of  the  major  frame.  The  uMinorFrStatus  indicates  the  lock  status 
of  the  minor  frame. 


struct  SuPcmFl 

{ 

uint64  t 

Header 

suIntraPckTime; 

// 

Reference  time 

uint32  t 

Reserved 

12; 

// 

uint32  t 

uMa j  orFr Status 

2; 

// 

Ma  j  or 

frame 

lock 

status 

uint32  t 

uMinorFrStatus 

2; 

// 

Minor 

frame 

lock 

status 

uint32  t 
}; 

Reserved 

16; 

// 

Figure  6-17.  Type  0x09  PCM  Data  Format  1  intra-packet  data  header. 


One  minor  frame  of  data  follows  the  intra-packet  data  header.  The  length  of  the  minor 
frame  data  is  not  included  in  the  data  packet.  The  data  length  must  be  detennined  from  the 
number  of  bits  in  a  minor  frame  specified  in  the  TMATS  parameter  P-d\MF2.  Minor  frames 
will  have  padding  bits  added  to  the  end  to  make  them  16  or  32-bit  aligned  depending  on  the 
value  of  bAlignment  flag  in  the  CSDW. 

6.5.8  Type  OxOA,  OxOF  PCM  Data,  Fonnat  2  -  Format  7.  Reserved  for  future  use. 

6.5.9  Type  0x10,  Time  Data,  Format  0.  Reserved  for  future  use. 

6.5.10  Type  0x11,  Time  Data,  Format  1  (IRIG/GPS/RTC).  Time  is  recorded  in  a  data  file  much 
like  any  other  data  source.  The  purpose  of  the  Time  Data  Format  1  packet  is  to  provide  a 
correlation  between  an  external  clock  source  and  the  recorder  internal  10  MHz  RTC.  The 
correlation  between  the  RTC  and  clock  time  is  described  in  more  detail  in  paragraph  6.6. 

The  time  data  packet  begins  with  the  CSDW  shown  in  Figure  6-18. 


struct  SuTimeFl 

{ 

uint32  t 

ChanSpec 

uTimeSrc 

4; 

// 

Time 

source 

uint32  t 

uTimeFmt 

4; 

// 

Time 

format 

uint32  t 

bLeapYear 

1; 

// 

Leap 

year 

uint32  t 

uDateFmt 

1; 

// 

Date 

format 

uint32  t 

uReservedl 

2; 

uint32  t 

}; 

uReserved2 

16; 

Figure  6-18.  Type  0x11  Time  Data  Format  1  CSDW. 
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The  uTimeSrc  field  indicates  the  source  is  for  the  time  used.  Note  that  this  field 
changed  slightly  between  the  2004  and  the  2005  release  of  Chapter  10.  The  uTimeFmt  field  is 
used  to  indicate  the  nature  and  type  of  the  source  of  external  time  source  applied  to  the  recorder. 
The  uDataFmt  field  is  used  to  determine  how  to  interpret  the  time  data  that  follows.  Time 
representation  in  Day  (i.e.  Day  of  the  Year)  format  is  shown  in  Figure  6-19.  Time  representation 
in  Day-Month- Year  format  is  shown  in  Figure  6-20.  The  bLeapYear  field  in  the  CSDW  is 
useful  to  convert  Day  of  the  Year  to  Day  and  Month  when  the  year  is  not  known. 


//  Time  message  -  Day  format 

struct  SuTime 

{ 

uintl6  t 

MsgDayFmt 

uTmn 

4; 

// 

Tens  of  milliseconds 

uintl6  t 

uHmn 

4; 

// 

Hundreds  of  milliseconds 

uintl6  t 

uSn 

4; 

// 

Units  of  seconds 

uintl6  t 

uTSn 

3; 

// 

Tens  of  seconds 

uintl6  t 

Reservedl 

1; 

// 

0 

uintl6  t 

uMn 

4; 

// 

Units  of  minutes 

uintl6  t 

uTMn 

3; 

// 

Tens  of  minutes 

uintl6  t 

Reserved2 

1; 

// 

0 

uintl6  t 

uHn 

4; 

// 

Units  of  hours 

uintl6  t 

uTHn 

2; 

// 

Tens  of  Hours 

uintl6  t 

Reserved3 

2; 

// 

0 

uintl6  t 

uDn 

4; 

// 

Units  of  day  number 

uintl6  t 

uTDn 

4; 

// 

Tens  of  day  number 

uintl6  t 

uHDn 

2; 

// 

Hundreds  of  day  number 

uintl6  t 
} ; 

Reserved4 

6 ; 

// 

0 

Figure  6-19.  Type  0x11  Time  Data  Format  1  structure,  day  format. 
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//  Time  message  -  DMY  format 

struct  SuTime 

{ 

uintl6  t 

MsgDmyFmt 

uTmn 

4; 

// 

Tens  of  milliseconds 

uintl6  t 

uHmn 

4; 

// 

Hundreds  of  milliseconds 

uintl6  t 

uSn 

4; 

// 

Units  of  seconds 

uintl6  t 

uTSn 

3; 

// 

Tens  of  seconds 

uintl6  t 

Reservedl 

1; 

// 

0 

uintl6  t 

uMn 

4; 

// 

Units  of  minutes 

uintl6  t 

uTMn 

3; 

// 

Tens  of  minutes 

uintl6  t 

Reserved2 

1; 

// 

0 

uintl6  t 

uHn 

4; 

// 

Units  of  hours 

uintl6  t 

uTHn 

2; 

// 

Tens  of  Hours 

uintl6  t 

Reserved3 

2; 

// 

0 

uintl6  t 

uDn 

4; 

// 

Units  of  day  number 

uintl6  t 

uTDn 

4; 

// 

Tens  of  day  number 

uintl6  t 

uOn 

4; 

// 

Units  of  month  number 

uintl6  t 

uTOn 

1; 

// 

Tens  of  month  number 

uintl6  t 

Reserved4 

3; 

// 

0 

uintl6  t 

uYn 

4; 

// 

Units  of  year  number 

uintl6  t 

uTYn 

4; 

// 

Tens  of  year  number 

uintl6  t 

uHYn 

4; 

// 

Hundreds  of  year  number 

uintl6  t 

uOYn 

2; 

// 

Thousands  of  year  number 

uintl6  t 

}; 

Reserved5 

2; 

// 

0 

Figure  6-20.  Type  0x11  Time  Data  Format  1  structure,  DMY  format 


6.5.11  Type  0x12  -  0x17,  Time  Data,  Format  2  -  Format  7.  Reserved  for  future  use. 

6.5.12  Type  0x18,  MIL-STD-1553  Data,  Format  0.  Reserved  for  future  use. 

6.5.13  Type  0x19,  MIL-STD-1553  Data,  Format  1  (MIL-STD-1553B  Data).  MIL-STD-1553 
Data,  Format  1  packets  are  used  to  record  the  MIL-STD-1553  message  transactions  on  a  bus.  In 
general,  the  1553  data  packet  will  contain  multiple  1553  messages. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-21.  The  uMsgCnt  field  indicates  the 
number  of  messages  contained  in  the  data  packet.  The  uTTB  field  indicates  the  1553  message 
bit  to  which  the  time  tag  corresponds. 


struct  Sul553Fl_ChanSpec 
{ 


uint32 

uint32 

t 

t 

uMsgCnt 

Reserved 

:  24; 

:  6; 

// 

Message  count 

uint32 

t 

uTTB 

:  2; 

// 

Time  tag  bits 

} 

Figure  6-21.  Type  0x19  MIL-STD-1553  Data  Format  1  CSDW. 
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The  individual  1553  messages  follow  the  CSDW.  Each  1553  message  has  an  intra¬ 
packet  time  stamp,  an  intra-packet  header  data  word,  and  then  the  actual  1553  message.  The 
layout  of  the  message  header  is  shown  in  Figure  6-22.  The  suIntPktTime  field  is  an  8-byte 
value.  The  specific  interpretation  of  this  field  is  determined  by  packet  header  flags.  This  time  is 
interpreted  as  a  RTC  value  as  depicted  in  Figure  6c5  if  Secondary  Headers  are  not  enabled  by 
Packet  Flags,  Bit  6.  If  Secondary  Headers  are  enabled,  then  the  format  of  the  intra-packet  time 
stamp  is  the  same  as  the  secondary  header,  determined  by  Packet  Flags,  Bits  2  and  3.  These 
formats  are  depicted  in  Figure  6A>  and  Figure  6-7.  Various  bit  flags  and  values  are  found  in  the 
intra-packet  data  header. 


//  Intra-message  header 

struct  Sul553Fl 

{ 

uint64  t 

Header 

suIntPktTime; 

// 

Reference  time 

uintl6  t 

Reservedl 

3; 

// 

Reserved 

uintl6  t 

bWordError 

1; 

uintl6  t 

bSyncError 

1; 

uintl6  t 

bWordCntError 

1; 

uintl6  t 

Reserved2 

3; 

uintl6  t 

bRespTimeout 

1; 

uintl6  t 

bFormatError 

1; 

uintl6  t 

bRT2RT 

1; 

uintl6  t 

bMsgError 

1; 

uintl6  t 

iBusID 

1; 

uintl6  t 

Reserved3 

2; 

uint8  t 

uGapTimel ; 

uint8  t 

uGapTime2 ; 

uintl6  t 
}; 

uMsgLen; 

Figure  6-22.  Type  0x19  MIL-STD-1553  Data  Format  1  intra-packet  header. 


The  amount  of  data  that  follows  the  intra-packet  header  is  variable.  The  data  length  in 
bytes  is  given  in  the  uMsgLen  field,  and  is  necessary  to  determine  the  amount  of  additional  data 
to  read  to  complete  the  message. 

The  layout  and  order  of  1553  Command  Word(s),  Status  Word(s),  and  Data  Word(s)  in 
the  recorded  1553  message  is  not  fixed  but  rather  is  the  same  is  it  would  be  found  "on  the  wire." 
It's  not  therefore  possible  to  define  a  fixed  data  structure  representation  for  the  message  data. 

The  first  word  in  the  data  will  always  be  a  Command  Word,  but  it  will  be  necessary  to  use  the 
Command  Word  as  well  as  the  bRT2RT  flag  to  detennine  the  offsets  of  the  other  message 
structures  such  as  the  Status  and  Data  Word(s).  The  layouts  of  the  various  types  of  1553 
messages  are  shown  in  Figure  6-23  and  Figure  6-24.  When  calculating  data  word  count,  be 
careful  to  take  Mode  Codes  and  word  count  wrap  around  into  account.  An  algorithm  to 
determine  the  number  of  data  words  in  a  message  is  shown  in  C-like  pseudo-code  in  Figure  6-25. 
This  algorithm  only  works  for  a  message  with  no  errors.  Otherwise,  Block  Status  Word  bits  and 
the  Length  Word  are  used  to  determine  data  and  status  words  actually  present. 
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BC  — >  RT 

RT  — » BC 

RT  — >  RT 

Mode  Code 
without  Data 

Transmit 
Mode  Code 
with  Data 

Receive  Mode 
Code  with 
Data 

Command 

Word 

Command 

Word 

Command 

Word 

Mode 

Command 

Mode 

Command 

Mode 

Command 

Data  Word  1 

Status  Word 

Command 

Word 

Status  Word 

Status  Word 

Data  Word 

•  •  • 

Data  Word  1 

Status  Word 

Data  Word 

Status  Word 

Data  Word  n 

•  •  • 

Data  Word  1 

Status  Word 

Data  Word  n 

•  •  • 

Data  Word  n 

Status  Word 

Figure  6-23.  1553  Message  word  layout. 


Figure  6-24.  1553  Broadcast  message  word  layout. 


//  Mode  Code  case 

if  (Subaddress  =  0x0000)  or 

(Subaddress  =  OxOOlf) 

if  (WordCount  &  0x0010) 

DataWordCount  =  1 

else 

DataWordCount  =  0 

//  Non-Mode  Code  case 

else 

if  (WordCount  =  0) 

DataWordCount  =  32 

else 

DataWordCount  =  WordCount 

Figure  6-25.  Algorithm  to  determine  1553  data  word  count. 


6.5.14  Type  OxlA,  MIL-STD-1553  Data,  Format  2  (16PP194  Bus).  MIL-STD-1553,  Format  2 
packets  are  used  to  record  data  from  the  16PP194  data  bus.  The  16PP194  data  bus  is  used  as  the 
F-16  weapons  multiplex  bus.  It  is  defined  in  document  16PP362A  Weapons  MUX  (WMUX) 
Protocol.  A  16PP194  transaction  consists  of  six  32-bit  words  consisting  of  a  16PP194 
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Command,  Command  Echo,  Response,  GO/NOGO,  GO/NOGO  Echo  and  Status  as  illustrated  in 
Figure  6-26.  Multiple  transactions  may  be  encoded  into  the  data  portion  of  a  single  packet. 


(1) 


(2) 


(4) 


(5) 


TX 


Command 


Command 

ECHO 


GO  NOGO 


GONOGO 

ECHO 


(3) 


(6) 


RX 


Response 


STATUS 


Figure  6-26.  16PP194  Message  transaction. 


The  layout  of  the  CSDW  is  show  in  Figure  6-27.  The  16PP194  packet  can  contain 
multiple  bus  transactions.  The  uMsgCnt  field  indicates  the  number  of  16PP194  messages  in  the 
packet. 


struct  Sul553F2_ChanSpec 
{ 

uint32_t  uMsgCnt;  //  Message  count 

}  ; 


Figure  6-27.  Type  OxlA  MIL-STD-1553  Data  Format  2  (16PP194)  CSDW. 

The  16PP194  message  word  is  26  bits  in  length  and  consists  of  16  data  bits,  four  address 
bits,  four  sub-address  bits,  a  parity  bit,  and  a  sync  bit.  Only  the  24  bits  of  data,  address,  and  sub¬ 
address  values  are  mapped  into  the  16PP194  recorded  data  word.  Sync  and  parity  bits  are  not 
recorded.  The  mapping  of  these  bits  is  shown  in  Figure  6-28. 
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MSB 


LSB 


16PP194  32-bit  Intra-Packet  Word  Format  (as  it  appears  in  the  data 
packet) 


Figure  6-28.  16PP194  to  IRIG  106  Chapter  10  data  bit  mapping. 


The  layout  of  the  recorded  16PP194  word  is  shown  in  Figure  6-29.  The  uDataWord 
field  contains  the  message  data.  The  uRiuSubAddr  field  is  the  Remote  Interface  Unit  (RIU) 
sub-address.  The  uRiuAddr  field  is  the  RIU  address.  The  bParityError  flag  indicates  a 
parity  error  occurred  during  reception  of  the  message.  The  bWordError  flag  indicates  a 
Manchester  decoding  error  occurred  during  reception  of  the  message.  The  uGap  field  indicates 
the  general  range  of  gap  time.  The  mapping  of  uGap  values  to  gap  time  ranges  can  be  found  in 
the  Chapter  10  standard.  The  uBusID  field  indicates  the  bus  on  which  the  message  occurred. 
Bus  identification  can  be  found  in  the  Chapter  10  standard.  The  layout  of  a  complete  16PP194 
transaction  is  shown  in  Figure  6-30. 


struct  SuSul6PP194  Word 
{ 


uint32 

t 

uDataWord; 

16; 

// 

Data  word  contents 

uint32 

t 

uRiuSubAddr 

4; 

// 

Parity  error  flag 

uint32 

t 

uRiuAddr 

4; 

// 

Parity  error  flag 

uint32 

t 

bParityError 

1; 

// 

Parity  error  flag 

uint32 

t 

bWordError 

1; 

// 

Manchester  error  flag 

uint32 

t 

uGap 

3; 

// 

Gap  time  indicator 

uint32 

}; 

t 

uBusID 

3; 

// 

Bus  ID  indicator 

Figure  6-29.  16PP 194  Word  layout. 
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struct  Sul6PP194  Transaction 


{ 

struct 

Sul 6PP1 94 

Word 

suComraand; 

struct 

Sul 6PP1 94 

Word 

suResponse; 

struct 

Sul 6PP1 94 

Word 

suCommandEcho ; 

struct 

Sul 6PP1 94 

Word 

suNoGo; 

struct 

Sul 6PP1 94 

Word 

suNoGoEcho; 

struct 

}; 

Sul 6PP1 94 

Word 

suStatus ; 

Figure  6-30.  16PP194  Transaction  layout. 

6.5.15  Type  OxlB  -  OxlF,  MIL-STD-1553  Data,  Fonnat  3  -  Format  7.  Reserved  for  future  use. 

6.5.16  Type  0x20,  Analog  Data,  Fonnat  0.  Reserved  for  future  use. 

6.5.17  Type  0x21,  Analog  Data,  Fonnat  1  (Analog  Data).  Analog  Data,  Fonnat  1  packets  are 
used  to  record  digitized  analog  signals.  In  general,  the  analog  data  packet  will  contain  multiple 
digitized  values  from  multiple  analog  channels.  Digitized  signal  values  can  be  stored  in  either  a 
unpacked  or  packed  fashion.  Unpacked  storage  describes  a  situation  in  which  each  sample 
occupies  one  16-bit  word  with  unused  bits  zero  fdled.  Packed  storage  concatenates  samples  to 
use  the  least  amount  of  storage  possible,  but  samples  will  straddle  16-bit  word  boundaries. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-3 1 .  Analog  packets  may  have  one  or 
multiple  CSDWs.  If  all  analog  subchannels  are  the  same  then  the  bSame  value  will  equal  "1" 
and  only  one  CSDW  will  be  present.  If  subchannels  are  configured  differently  then  there  will  be 
one  CSDW  for  each  subchannel.  The  uMode  field  indicates  the  whether  the  samples  are  stored 
in  packed  or  unpacked  mode,  and  how  unused  bits  are  zero  filled.  The  uLength  field  indicates 
the  number  of  bits  in  digitized  sample.  The  uSubChan  field  indicates  the  number  of  the  current 
subchannel.  The  uTotChan  field  indicates  the  total  number  of  subchannels  in  the  packet.  The 
uFactor  field  indicates  the  exponent  of  the  power  of  2  sampling  rate  factor  denominator. 


struct  SuAnalogFl  ChanSpec 
{ 


uint32 

t 

uMode 

2; 

// 

Packed  or  Unpacked 

uint32 

t 

uLength 

6; 

// 

Bits  in  A/D  value 

uint32 

t 

uSubChan 

8; 

// 

Subchannel  number 

uint32 

t 

uTotChan 

8; 

// 

Total  number  of  subchannels 

uint32 

t 

uFactor 

4; 

// 

Sample  rate  exponent 

uint32 

t 

bSame 

1; 

// 

One/multiple  CSDW 

uint32 

}; 

t 

iReserved 

3; 

// 

Figure.6-31.  Type  0x21  Analog  Data  Fonnat  1  CSDW. 

Sample  rate,  Least  Significant  Bit  (LSB)value,  offset,  and  other  analog  parameters  are 
recorded  in  the  TMATS  packet.  The  layout  of  the  sequential  samples  is  described  in  detail  in  the 
Chapter  10  standard. 
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6.5. 18  Type  0x22  -  0x27,  Analog  Data,  Format  2  -  Format  7.  Reserved  for  future  use. 

6.5.19  Type  0x28,  Discrete  Data,  Format  0.  Reserved  for  future  use. 

6.5.20  Type  0x29,  Discrete  Data,  Format  1  (Discrete  Data).  Discrete  Data,  Format  1  packets  are 
used  to  record  the  state  of  discrete  digital  signals.  In  general,  the  discrete  data  packet  will 
contain  multiple  values  from  multiple  discrete  events. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-32.  The  uRecordState  and 
uAlignment  flags  are  components  of  the  discrete  packet  Mode  field.  See  the  Chapter  10 
standard  for  further  details.  The  uLength  value  is  the  number  of  Discrete  Data  message  that 
follow  in  the  packet. 


struct  SuDiscreteFl_ChanSpec 
{ 


uint32 

t 

uRecordState 

1; 

// 

Record 

on  state/time 

uint32 

t 

uAlignment 

1; 

// 

Data  alignment 

uint32 

t 

uReservedl 

1; 

// 

uint32 

t 

uLength 

5; 

// 

Number 

of  bits 

uint32 

}; 

t 

uReserved2 

24; 

// 

Figure  6-32.  Type  0x29  Discrete  Data  Format  1  CSDW. 


The  layout  of  the  Discrete  Data  message  is  shown  in  Figure  6-33.  Each  message  contains 
a  time  stamp  and  the  state  of  the  discrete  data  input  signals.  The  suIntraPckTime  field  in 
the  data  structures  of  represents  event  time  in  either  48-bit  relative  time  format  derived  from  the 
RTC  (format  shown  in  Figure  6-5)  ,  or  as  absolute  time.  If  this  time  is  absolute  time,  it  is  in 
either  Chapter  4  weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time  format 
(format  shown  in  Figure  6-7). 


struct  SuDiscreteFl 

{ 

uint64  t 

suIntraPckTime; 

// 

Intra-packet  time  stamp 

uint32  t 

suData; 

// 

Data  about  the  event 

}; 

Figure  6-33.  Type  0x29  Discrete  Data  Format  1  message. 


The  IRIG  07  Chapter  10  and  prior  standard  incorrectly  states  that  Bit  7  of  the  Packet 
Flags  (in  the  packet  header)  is  used  to  determine  if  the  intra-packet  time  is  relative  time  or 
absolute  time.  The  correct  bit  to  use  is  Bit  6.  It  is  anticipated  that  with  will  be  corrected  in  a 
future  release 

6.5.21  Type  0x2A  -  0x2F,  Discrete  Data,  Format  2  -  Format  7.  Reserved  for  future  use. 
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6.5.22  Type  0x30,  Message  Data,  Format  0  (Generic  Message  Data).  Message  Data  packets  are 
used  to  record  data  from  sources  that  do  not  have  a  defined  packet  type  in  the  Chapter  10 
standard.  Examples  of  this  might  be  the  H-009  bus  found  on  older  F-15  aircraft  or  the  High 
Speed  Data  Bus  (HSDB)  bus  found  on  older  F-16  aircraft.  The  Chapter  10  standard  implies  that 
Message  Data  packets  represent  "serial"  communications  data.  In  practice,  there  are  few 
restrictions  on  the  content  or  source  of  the  data  for  Message  Data  packets. 

Message  Data  packets  do  not  contain  any  field  to  indicate  what  format  or  type  of  data 
they  contain  or  how  to  interpret  the  data  contents.  Message  Data  packets  are  distinguished  by 
their  Channel  ID  and  Subchannel  values.  The  TMATS  setup  provides  fields  specifying  a 
subchannel  name  (R-x\MCNM-n-m)  for  each  subchannel  number  (R-x\MSCN-m-n)  and 
Channel  ID  (R-x\TKl-m).  Use  the  subchannel  name  to  determine  how  to  decode  each  Channel 
ID  /  subchannel  combination.  There  currently  is  no  standard  for  subchannel  names  and  no 
registry  of  "well  known"  names. 

Individual  Message  Data  messages  are  restricted  to  no  more  than  65,536  (64k)  bytes.  A 
Message  Data  packet  can  contain  multiple  data  messages,  a  single  data  message,  or  a  segment  of 
a  large  (greater  than  64k)  data  message.  A  Message  Data  packet  consists  of  a  CSDW  followed 
by  one  or  more  messages.  The  layout  of  the  CSDW  is  shown  in  Figure  6-34.  The  uType  value 
indicates  whether  the  data  is  a  complete  message  or  a  segment  of  a  large  message.  The 
uCounter  value  indicates  either  the  number  of  data  packets  to  follow  or,  for  the  segmented 
case,  the  segment  number  of  the  large  data  packet  segment  that  follows. 


struct  SuMessageF0_ChanSpec 
{ 


uint32 

t 

uCounter 

:  16; 

// 

Message/segment  counter 

uint32 

t 

uType 

:  2; 

// 

Complete/segment  type 

uint32 

t 

uReserved 

:  14; 

}  SuMessageF0_ChanSpec; 

Figure  6-34.  Type  0x30  Message  Data  Format  0  CSDW. 

The  layout  of  the  Message  Data  message  intra-packet  header  is  shown  in  Figure  6-35. 
Each  header  contains  a  time  stamp  and  some  additional  information  about  the  data  that  follows 
in  the  message.  The  suIntraPckTime  field  in  the  intra-packet  data  structure  represents  event 
time  in  either  48-bit  relative  time  format  derived  from  the  RTC  (format  shown  in  Figure  6-5)  ,  or 
as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either  Chapter  4  weighted  48-bit  time 
(format  shown  in  Figure  6-6)  or  IEEE  1588  time  format  (format  shown  in  Figure  6-7).  The 
uMsgLength  value  indicates  the  number  of  data  bytes  in  the  message.  The  uSubChannel 
value  identifies  the  specific  subchannel  from  which  this  data  came.  The  message  data 
immediately  follows  the  intra-packet  header.  Note  that  an  even  number  of  bytes  is  allocated  for 
message  data.  If  the  data  contains  an  odd  number  of  bytes,  then  one  unused  filler  byte  is  inserted 
at  the  end  of  the  data.  The  bFmtError  and  bDataError  flags  indicate  that  errors  have 
occurred  in  the  reception  of  the  data.  The  recorded  data  may,  therefore,  be  invalid  and  unusable. 
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struct  SuMessageFO_Header 
{ 


uint64 

t 

suIntraPckTime; 

// 

Reference  time 

uint32 

t 

uMsgLength 

16; 

// 

Message  length 

uint32 

t 

uSubChannel 

14; 

// 

Subchannel  number 

uint32 

t 

bFmtError 

1; 

// 

Format  error  flag 

uint32 

}; 

t 

bDataError 

1; 

// 

Data  error  flag 

Figure  6-35.  Type  0x30  Message  Data  Format  0  intra-packet  header. 

The  IRIG  106-07  Chapter  10  standard,  and  earlier  versions,  incorrectly  states  that  Bit  7  of 
the  Packet  Flags  (in  the  packet  header)  is  used  to  determine  if  the  intra-packet  time  is  relative 
time  or  absolute  time.  The  correct  bit  to  use  is  Bit  6.  It  is  anticipated  that  with  will  be  corrected 
in  a  future  release 

6.5.23  Type  0x31  -  0x37,  Message  Data,  Format  1  -  Format  7.  Reserved  for  future  use. 

6.5.24  Type  0x38,  ARINC  429  Data,  Format  0  (ARINC  429  Data).  The  ARINC  429  Data, 
Format  0  packets  are  used  to  record  data  messages  from  an  ARINC  429  data  bus.  ARINC  429  is 
a  unidirectional  data  bus  that  is  commonly  found  on  commercial  and  transport  aircraft.  Words 
are  32  bits  in  length  and  most  messages  consist  of  a  single  data  word.  Messages  are  transmitted 
at  either  12.5  or  100  kbit/s  from  a  transmitting  system  to  one  or  more  receiving  systems.  The 
transmitter  is  always  transmitting  either  32-bit  data  words  or  the  NULL  state.  An  ARINC  data 
packet  can  contain  multiple  messages. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-36.  The  uMsgCount  field  indicates  the 
number  of  recorded  ARINC  429  messages. 


struct  SuArinc429F0  ChanSpec 
{ 

uint32  t  uMsgCount 

:  16; 

//  Message  count 

uint32  t  Reserved 

} 

:  16; 

// 

Figure  6-36.  Type  0x60  ARINC  429  Data  Format  0  CSDW. 


Individual  ARINC  429  data  messages  follow  the  CSDW.  Each  message  is  preceded  with 
an  intra-packet  data  header  followed  by  the  ARINC  429  data  word. 

The  layout  of  the  ARINC  429  data  message  intra-packet  data  header  is  shown  in 
Figure  6-37.  The  uGapTime  field  is  the  time  between  the  beginning  of  the  preceding  bus  word 
and  the  beginning  of  the  current  bus  word  in  0.1  microsecond  increments.  The  uBusSpeed 
field  indicates  the  bit  rate  of  the  recorded  bus  message.  The  bParityError  flag  indicates  the 
presence  of  a  parity  data  error.  The  bFormatError  flag  indicates  the  presence  of  one  of 
several  types  of  data  format  errors.  The  uBusNum  field  identifies  the  specific  ARINC  429  bus 
associates  with  the  recorded  data  message. 
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struct  SuArinc42 9F0_Header 
{ 


uint32  t 

uint32  t 

uGapTime 

Reserved 

20; 

1; 

// 

// 

Gap  Time 

uint32  t 

uBusSpeed 

1; 

// 

Bus  Speed 

uint32  t 

bParityError 

1; 

// 

Parity  Error 

uint32  t 

bFormatError 

1; 

// 

Data  type 

uint32  t 

uBusNum 

8; 

// 

Bus  number 

} 


Figure  6-37.  Type  0x38  A  RING  429  Data  Format  0  intra-packet  data  header. 

The  layout  of  the  individual  ARINC  429  data  work  is  shown  in  Figure  6-38.  Refer  to  the 
ARINC  429  standard  for  the  interpretation  of  the  specific  data  fields. 


struct  SuArinc429F0  Data 

{ 

uint32  t  uLabel 

8; 

// 

Label 

uint32  t 

uSDI 

2; 

// 

Source/Destination  ID 

uint32  t 

uData 

19; 

// 

Data 

uint32  t 

uSSM 

2; 

// 

Sign/Status  Matrix 

uint32  t 

uParity 

1; 

// 

Parity 

} 

Figure  6-38.  Type  0x38  ARINC  429  data  format. 


6.5.25  Type  0x39  -  0x3F,  ARINC  429  Data,  Format  1  -  Format  7.  Reserved  for  future  use. 

6.5.26  Type  0x40,  Video  Data,  Fonnat  0  (MPEG-2/H.264  Video).  Video  Data,  Format  0 
packets  are  used  to  record  digitized  video  and  associated  audio  signals.  Format  0  packets  are 
restricted  to  contain  only  Moving  Picture  Experts  Group  (MPEG-2)  Transport  Stream  (TS) 
packets.  Video  can  be  encoded  with  either  MPEG-2  Main  Profile  Main  Level  (MP@ML) 
encoding  or  H.264  (also  know  as  MPEG-4  Part  10  and  MPEG-4  AVC)  Main  Profile  Level  3 
(MP@L3)  encoding.  The  H.264  encoder  is  usually  the  preferred  encoder  for  lower  bit  rate 
video.  This  encoding  is  usually  referred  to  as  Standard  Definition  (SD),  and  has  a  maximum 
resolution  of  720  by  576  pixels  but  is  frequently  less. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-39.  The  uType  value  indicates  the 
specific  video  encoding  type  in  the  MPEG-2  stream.  This  field  was  first  defined  in  IRIG  106-07 
(Header  Version  0x03).  It  was  reserved  and  zero  filled  in  previous  versions  of  Chapter  10.  The 
bKLV  flag  indicates  the  presence  of  Key-Length- Value  (KLV)  metadata  fields  in  the  video  data. 
The  bSRS  flag  indicates  whether  or  not  the  embedded  video  clock  is  synchronized  with  the 
RTC.  The  blntraPckHdr  flag  indicates  the  presence  of  intra-packet  header  data  in  each 
video  data  message.  The  bET  flag  indicates  the  presence  of  embedded  time  in  the  video  data. 
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struct  SuVideoFC 

{ 

uint32  t 

ChanSpec 

Reserved 

24; 

uint32  t 

uType 

4; 

// 

Payload  type 

uint32  t 

bKLV 

1; 

// 

KLV  present 

uint32  t 

bSRS 

1; 

// 

SCR/RTC  Sync 

uint32  t 

blntraPckHdr 

1; 

// 

Intra-Packet  Header 

uint32  t 

}; 

bET 

1; 

// 

Embedded  Time 

Figure  6-39.  Type  0x40  Video  Data  Format  0  CSDW. 


MPEG-2  TS  packets  follow  the  CSDW.  TS  packets  are  a  fixed  size  of  188  bytes.  If  the 
blntraPckHdr  flag  is  set,  each  TS  packet  will  be  preceded  with  an  eight  byte  intra-packet  time 
stamp.  The  intra-packet  time  represents  TS  time  in  either  48-bit  relative  time  format  derived 
from  the  RTC  (format  shown  in  Figure  6-5)  ,  or  as  absolute  time.  If  this  time  is  absolute  time,  it 
is  in  either  Chapter  4  weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time 
format  (shown  in  Figure  6-7).  Format  0  does  not  include  a  packet  count;  instead,  the  number  of 
TS  packets  can  be  calculated  from  the  size  of  the  data  packet  found  in  the  Chapter  10  header. 

Format  0  video  data  can  be  readily  decoded  with  commonly  available  MPEG  libraries 
such  as  the  open  source  fftnpeg  library.  A  188  byte  TS  packet  is  best  thought  of  as  contiguous 
stream  of  1504  bits.  TS  packets  are  stored  in  Format  0  packets  as  a  series  of  16-bit  words.  The 
first  Fonnat  0  data  word  holds  the  first  16  TS  packet  bits.  TS  packet  bit  0  (the  first  TS  bit)  is  the 
leftmost  bit  (msb)  in  the  first  Format  0  packet  word.  Note  that  the  description  of  this  bit  ordering 
alignment  in  a  Format  0  packet  has  been  frequently  depicted  wrong  in  the  various  IRIG  106 
Chapter  10  releases.  MPEG  decoder  libraries  such  as  ffinpeg  commonly  take  as  input  a  188  byte 
array  of  TS  data.  Due  to  the  use  of  16-bit  words  to  store  TS  data  in  Format  0  packet,  TS  data 
needs  to  be  byte  swapped  as  it  is  read  from  a  Chapter  10  data  file  and  put  into  a  buffer  for 
decoding  by  a  software  library  expecting  byte  aligned  TS  data.  Chapter  10  requires  audio  to  be 
encoded  with  the  video  stream  using  audio  encoding  inherent  with  MPEG  format  video  streams. 
There  are  instances  where  vendors  have  encoded  audio  in  a  separate  analog  channel  to  meet 
special  requirements. 

6.5.27  Type  0x41,  Video  Data,  Fonnat  1  (ISO  13818-1  MPEG-2).  Video  Data,  Fonnat  1 
packets  are  used  to  record  digitized  video  and  associated  audio  signals.  Format  1  packets  can 
support  the  complete  MPEG-2  ISO/IEC  13818-1:2000  standard  for  both  Program  Streams  (PS) 
and  Transport  Streams  (TS).  Any  Profile  and  Level  combination  can  be  used  in  Format  1. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-40.  The  uPacketCnt  value  is  the 
number  of  MPEG-2  packets  in  the  data  packet.  The  uType  value  indicates  whether  the  video 
packet  is  a  PS  or  TS.  The  uMode  value  indicates  whether  the  video  packet  uses  constant  or 
variable  rate  encoding.  The  bET  flag  indicates  the  presence  of  embedded  time  in  the  video  data. 
The  uEPL  value  indicates  the  video  packet  encoding  Profile  and  Level  used.  The 
blntraPckHdr  flag  indicates  the  presence  of  intra-packet  header  data  in  each  video  data 
message.  The  bSRS  flag  indicates  whether  or  not  the  embedded  video  clock  is  synchronized 
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with  the  RTC.  The  bKLV  flag  indicates  the  presence  of  Key-Length- Value  (KLV)  metadata 
fields  in  the  video  data. 


struct  SuVideoFl_ChanSpec 
{ 

uint32_t  uPacketCnt  :  12; 
uint32_t  uType  :  1; 
uint32_t  uMode  :  1; 
uint32  t  bET  :  1; 
uint32_t  uEPL  :  4; 
uint32_t  blntraPckHdr  :  1; 
uint32_t  bSRS  :  1; 
uint32_t  bKLV  :  1; 
uint32  t  uReserved  :  10; 
}  ; 


/ /  Number  of  packets 
//  TS/PS  type 
//  Const/Var  mode 
//  Embedded  Time 
//  Encoding  Profile  and  Level 
//  Intra-Packet  Header 
//  SCR/RTC  Sync 
/ /  KLV  present 


Figure  6-40.  Type  0x40  Video  Data  Format  1  CSDW. 


MPEG-2  PS  or  TS  packets  follow  the  CSDW.  TS  packets  are  a  fixed  length  of  188 
bytes,  but  PS  packers  are  variable  length.  If  the  blntraPckHdr  flag  is  set,  each  MPEG-2 
packet  will  be  preceded  with  an  eight  byte  intra-packet  time  stamp.  The  intra-packet  time 
represents  MPEG  packet  time  in  either  48-bit  relative  time  format  derived  from  the  RTC  (format 
shown  in  Figure  6-5),  or  as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either  Chapter  4 
weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time  format  (fonnat  shown  in 
Figure  6-7). 

Format  1  does  not  include  a  method  to  separate  individual  MPEG  packets  from  within  the 
Format  1  packet  other  than  determining  the  MPEG  packet  size  from  the  MPEG  packet  data. 
Determining  MPEG  packet  size  is  fairly  complicated  and  involves  a  good  knowledge  of  MPEG 
internal  data  structures.  For  this  reason,  the  use  of  intra-packet  headers  between  MPEG  packets 
should  be  carefully  considered.  It  could  make  decoding  Format  1  packets  quite  complicated. 

Chapter  10  provides  little  guidance  for  the  specific  layout  of  the  MPEG-2  data  payload. 

In  practice,  Video  Data  Format  1  MPEG-2  data  is  stored  in  “native”  format  within  the  IRIG  data 
packet.  The  data  is  byte  ordered  within  the  data  packet  in  the  same  order  as  the  MPEG-2  data 
packet.  Unlike  Video  Data  Format  0  data,  Format  1  MPEG-2  packets  do  not  require  byte 
swapping  before  decoding. 

Chapter  10  requires  audio  to  be  encoded  with  the  video  stream  using  audio  encoding  inherent 
with  MPEG  format  video  streams.  There  are  instances  where  vendors  have  encoded  audio  in  a 
separate  analog  channel  to  meet  special  requirements. 


6.5.28  Type  0x42,  Video  Data,  Fonnat  2  (ISO  14496  MPEG-4  Part  10  AVC/H.264).  Video 
Data,  Format  2  packets  are  used  to  record  digitized  video  and  associated  audio  signals.  Format  2 
packets  can  support  the  complete  MPEG-2  ISO  International  Electrotechnical  Commission 
(ISO/IEC)  13818-1:2000  standard  for  both  Program  Streams  (PS)  and  Transport  Streams  (TS), 
and  provides  all  H.264  (also  known  as  MPEG-4  Part  10  and  MPEG-4  AVC)  encoding  Levels 
and  Profiles. 
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The  layout  of  the  CSDW  is  shown  in  Figure  6-41.  The  uPacketCnt  value  is  the 
number  of  MPEG-2  packets  in  the  data  packet.  The  uType  value  indicates  whether  the  video 
packet  is  a  PS  or  TS.  The  uMode  value  indicates  whether  the  video  packet  uses  constant  or 
variable  rate  encoding.  The  bET  flag  indicates  the  presence  of  embedded  time  in  the  video  data. 
The  uEP  value  indicates  the  video  packet  encoding  Profile  used.  The  blntraPckHdr  flag 
indicates  the  presence  of  intra-packet  header  data  in  each  video  data  message.  The  bSRS  flag 
indicates  whether  or  not  the  embedded  video  clock  is  synchronized  with  the  RTC.  The  bKLV 
flag  indicates  the  presence  of  Key-Length- Value  (KLV)  metadata  fields  in  the  video  data.  The 
uEL  value  indicates  the  video  packet  encoding  Profile  and  Level  used.  The  uAET  field  indicates 
the  type  of  AVC/H.264  audio  encoding  used. 


struct  SuVideoF2_ChanSpec 
{ 


uint32 

t 

uPacketCnt 

12; 

// 

Number  of  packets 

uint32 

t 

uType 

1; 

// 

TS/PS  type 

uint32 

t 

uMode 

1; 

// 

Const/Var  mode 

uint32 

t 

bET 

1; 

// 

Embedded  Time 

uint32 

t 

uEP 

4; 

// 

Encoding  Profile 

uint32 

t 

blntraPckHdr 

1; 

// 

Intra-Packet  Header 

uint32 

t 

bSRS 

1; 

// 

SCR/RTC  Sync 

uint32 

t 

bKLV 

1; 

// 

KLV  present 

uint32 

t 

uEL 

4; 

// 

Encoding  Level 

uint32 

t 

uAET 

1; 

// 

Audio  Encoding  Type 

uint32 

}; 

t 

uReserved 

5; 

Figure  6-41.  Type  0x40  Video  Data  Format  2  CSDW. 

MPEG-2  PS  or  TS  packets  follow  the  CSDW.  TS  packets  are  a  fixed  length  of  188 
bytes,  but  PS  packers  are  variable  length.  If  the  blntraPckHdr  flag  is  set,  each  MPEG-2 
packet  will  be  preceded  with  an  eight  byte  intra-packet  time  stamp.  The  intra-packet  time 
represents  MPEG  packet  time  in  either  48-bit  relative  time  format  derived  from  the  RTC  (format 
shown  in  Figure  6-5)  ,  or  as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either  Chapter  4 
weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time  format  (fonnat  shown  in 
Figure  6-1). 

Format  2  does  not  include  a  method  to  separate  individual  MPEG  packets  from  within  the 
Format  2  packet  other  than  detennining  the  MPEG  packet  size  from  the  MPEG  packet  data. 
Determining  MPEG  packet  size  is  fairly  complicated  and  involves  quite  a  bit  of  knowledge  about 
MPEG  internal  data  structures.  For  this  reason,  the  use  of  intra-packet  headers  between  MPEG 
packets  should  be  carefully  considered.  It  could  make  decoding  Format  2  packets  quite 
complicated. 

Chapter  10  provides  little  guidance  for  the  specific  layout  of  the  MPEG-4  data  payload. 

In  practice,  Video  Data  Format  2  MPEG-4  data  is  stored  in  “native”  format  within  the  IRIG  data 
packet.  The  data  is  byte  ordered  within  the  data  packet  in  the  same  order  as  the  MPEG-4  data 
packet.  Unlike  Video  Data  Format  0  data,  Format  2  MPEG-4  packets  do  not  require  byte 
swapping  before  decoding. 
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Chapter  10  requires  audio  to  be  encoded  with  the  video  stream  using  audio  encoding 
inherent  with  MPEG  format  video  streams.  There  are  instances  where  vendors  have  encoded 
audio  in  a  separate  analog  channel  to  meet  special  requirements. 

6.5.29  Type  0x43  -  0x47,  Video  Data,  Format  3  -  Format  7.  Reserved  for  future  use. 

6.5.30  Type  0x48,  Image  Data,  Format  0  (Image  Data).  Image  Data,  Fonnat  0  packets  are  used 
to  record  digitized  video  images. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-42.  The  uLength  value  is  the  number 
bytes  in  each  segment.  The  blntraPckHdr  flag  indicated  the  presence  of  the  intra-packet  data 
header.  The  uSum  value  indicates  if  and  how  an  image  is  segmented  in  the  data  packet.  The 
uPart  value  indicates  which  part  of  a  possibly  segmented  image  is  contained  in  the  data  packet. 


struct  SuImageFO 
{ 

uint32  t 

ChanSpec 

uLength 

:  27; 

// 

Segment  byte 

length 

uint32  t 

blntraPckHdr 

:  1; 

// 

Intra-packet 

header  flag 

uint32  t 

uSum 

:  2; 

// 

uint32  t 
}; 

uPart 

:  2; 

// 

Figure  6-42.  Type  0x48  Image  Data  Format  0  CSDW. 


Individual  image  data  messages  follow  the  CSDW.  Each  message  may  have  an  optional 
intra-packet  data  header  followed  by  the  image  data.  The  intra-packet  data  header,  if  present 
(indicated  by  blntraPckHdr  =  1),  is  an  eight  byte  representation  of  time  in  either  48-bit 
relative  time  format  derived  from  the  RTC  (format  shown  in  Figure  6-5)  ,  or  as  absolute  time.  If 
this  time  is  absolute  time,  it  is  in  either  Chapter  4  weighted  48-bit  time  (format  shown  in 
Figure  6-6)  or  IEEE  1588  time  format  (format  shown  in  Figure  6-7). 

The  format  of  the  image  data  portion  of  the  packet  is  not  specified  in  Chapter  10.  The 
image  format  is  specified  in  the  TMATS  setup  record  attribute  “R-x\SIT-n”.  Note  that  an 
even  number  of  bytes  is  allocated  for  message  data.  If  the  data  contains  an  odd  number  of  bytes, 
then  one  unused  filler  byte  is  inserted  at  the  end  of  the  data. 

Chapter  10  of  IRIG  106-07  (and  prior  editions  of  the  standard)  incorrectly  state  that  Bit  7 
of  the  Packet  Flags  (in  the  packet  header)  is  used  to  determine  if  the  intra-packet  time  is  relative 
time  or  absolute  time.  The  correct  bit  to  use  is  Bit  6.  This  handbook  is  based  on  (and  correlates 
to)  the  IRIG  106-07  edition;  however  the  "bit  7"  error  will  be  corrected  in  future  releases  of  this 
handbook. 

6.5.31  Type  0x49,  Image  Data,  Format  1  (Still  Imagery).  Image  Data,  Format  1  packets  are 
used  to  record  digitized  still  images.  Several  formats  for  image  compression  are  supported  by 
Format  1. 
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The  layout  of  the  CSDW  is  shown  in  Figure  6-43.  The  uFormat  value  indicates  the 
format  of  the  image  data.  The  blntraPckHdr  flag  indicated  the  presence  of  the  intra-packet 
data  header.  The  uSum  value  indicates  if  and  how  an  image  is  segmented  in  the  data  packet. 
The  uPart  value  indicates  which  part  of  a  possibly  segmented  image  is  contained  in  the  data 
packet. 


struct  SuImageFl 
{ 

uint32  t 

ChanSpec 

uReserved 

23; 

// 

uint32  t 

uFormat 

4; 

// 

Image  format 

uint32  t 

blntraPckHdr 

1; 

// 

Intra-packet  header  flag 

uint32  t 

uSum 

2; 

// 

uint32  t 
} ; 

uPart 

2; 

// 

Figure  6-43.  Type  0x49  Image  Data  Format  1  CSDW. 


Individual  image  data  messages  follow  the  CSDW.  Each  message  may  have  an  optional 
intra-packet  data  header  (indicated  by  blntraPckHdr  =1)  followed  by  the  image  data.  The 
format  of  the  intra-packet  data  header  is  shown  in  Figure  6-44.  The  suIntrPckTime  value  is 
an  eight  byte  representation  of  time  in  either  48-bit  relative  time  format  derived  from  the  RTC 
(format  shown  in  Figure  6-5)  ,  or  as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either 
Chapter  4  weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time  format  (format 
shown  in  Figure  6-7).  The  uMsgLength  value  indicates  the  length  of  the  following  still  image  or 
segment. 


struct  SuImageFl^Header 
{ 

uint64  t  suIntraPckTime;  //  Reference  time 
uint32  t  uMsgLength;  //  Message  length 
}  ; 


Figure  6-44.  Type  0x49  Image  Data  Fonnat  1  intra-packet  header. 

Chapter  10  of  IRIG  106-07  (and  prior  editions  of  the  standard)  incorrectly  state  that  Bit  7 
of  the  Packet  Flags  (in  the  packet  header)  is  used  to  determine  if  the  intra-packet  time  is  relative 
time  or  absolute  time.  The  correct  bit  to  use  is  Bit  6.  This  handbook  is  based  on  (and  correlates 
to)  the  IRIG  106-07  edition;  however  the  "bit  7"  error  will  be  corrected  in  future  releases  of  this 
handbook. 

6.5.32  Type  0x4A  -  0x4F,  Image  Data,  Format  2  -  Format  7.  Reserved  for  future  use. 

6.5.33  Type  0x50,  Universal  Asynchronous  Receiver  and  Transmitter  (UART)  Data,  Format  0 

(UART  Data).  UART  Data,  Format  0  packets  are  used  to  record  character  data  from  an 
asynchronous  serial  interface.  Generally,  the  UART  data  packet  will  contain  multiple  buffers  of 
serial  data.  The  Chapter  10  standard  has  no  provisions  for  specifying  how  characters  will  be 
grouped  into  blocks  of  data  other  than  the  100  msec  maximum  data  block  time.  It  is  common  for 
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recorder  vendors  to  provide  a  mechanism  for  determining  serial  message  boundaries  and 
recording  a  complete  serial  message  into  a  single  UART  data  message  based  on  detecting  "dead 
time"  between  messages. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-45.  The  blntraPckHdr  flag  is  used  to 
indicate  if  an  optional  intra-packet  time  stamp  is  included  with  each  UART  data  message. 


struct  SuUartFO  ChanSpec 
{ 

uint32  t  uReserved 

:  31; 

uint32  t  blntraPckHdr 

}  SuUartFO  ChanSpec; 

:  1 

Figure  6-45.  Type  0x50  UART  Data  Format  0  CSDW. 


The  UART  data  message  may  have  an  optional  intra-packet  time  stamp.  If  so,  this  time 
field  will  be  an  8  byte  value.  Time  is  represented  in  either  48-bit  relative  time  format  derived 
from  the  RTC  (format  shown  in  Figure  6-5)  ,  or  as  absolute  time.  If  this  time  is  absolute  time,  it 
is  in  either  Chapter  4  weighted  48-bit  time  (format  shown  in  Figure  6-6)  or  IEEE  1588  time 
format  (format  shown  in  Figure  6-7). 

The  layout  of  the  UART  Data  message  intra-packet  data  header  is  shown  in  Figure  6-46. 
The  uDataLength  value  indicates  the  number  of  data  bytes  in  the  message.  The 
uSubChannel  value  identifies  the  specific  subchannel  this  data  came  from.  The  message  data 
immediately  follows  the  intra-packet  data  header.  Note  that  an  even  number  of  bytes  is  allocated 
for  UART  data.  If  the  data  contains  an  odd  number  of  bytes,  then  one  unused  filler  byte  is 
inserted  at  the  end  of  the  data.  The  bParityError  flag  indicates  that  errors  have  occurred  in 
the  reception  of  the  data.  The  recorded  data  may,  therefore,  be  invalid  and  unusable. 


struct  SuUartFO 

{ 

uintl6  t 

DataHeader 

uDataLength 

:  16; 

/ /  Num  of  bytes  of  UART  data 

uintl6  t 

uSubChannel 

:  14; 

//  Subchannel  for  following  data 

uintl6  t 

uReserved 

:  1; 

uintl6  t 

}; 

bParityError 

:  1; 

//Parity  Error 

Figure  6-46.  Type  0x40  UART  Data  Format  0  intra-packet  data  header. 


Chapter  10  of  IRIG  106-07  (and  prior  editions  of  the  standard)  incorrectly  state  that  Bit  7 
of  the  Packet  Flags  (in  the  packet  header)  is  used  to  determine  if  the  intra-packet  time  is  relative 
time  or  absolute  time.  The  correct  bit  to  use  is  Bit  6.  This  handbook  is  based  on  (and  correlates 
to)  the  IRIG  106-07  edition;  however  the  "bit  7"  error  will  be  corrected  in  future  releases  of  this 
handbook. 

6.5.34  Type  0x51  -  0x57,  UART  Data,  Format  1  -  Fonnat  7.  Reserved  for  future  use. 
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6.5.35  Type  0x58,  IEEE  1394  Data,  Format  0  (IEEE  1394  Transaction).  IEEE  1394  Data, 
Format  0  packets  are  used  to  record  data  messages  at  the  transaction  layer  of  the  IEEE  1394 
serial  data  bus.  Currently  IEEE  1394,  IEEE  1995,  IEEE  1394a,  and  IEEE  1394b  are  supported. 
There  are  two  major  classes  of  IEEE  1394  data  transfer,  synchronous  and  isochronous. 
Synchronous  data  transfer  is  used  to  transport  real  time  data  streams  such  as  video.  Isochronous 
transfer  is  used  to  transport  other  non-time  critical  data  on  a  best  effort  basis  without  latency  or 
throughput  guarantees. 

At  the  lowest  network  level,  IEEE  1394  defines  three  types  of  bus  packets;  a  PHY 
packet,  a  Primary  packet,  and  an  Acknowledgement  packet.  There  are  several  different  types  of 
Primary  packets.  Primary  packets  contain  a  Transaction  Code  to  distinguish  them. 

There  are  three  different  types  of  IEEE  1394  Data,  Format  0  packets.  The  Chapter  10  standard 
refers  to  these  as  Type  0,  Type  1,  and  Type  2.  Type  0  packets  are  used  to  record  bus  events  such 
as  Bus  Reset.  Type  1  packets  are  used  to  record  synchronous  streams  only  (Primary  packets 
with  a  TCODE  of  OxOA).  Type  2  packets  are  for  more  general  purpose  use  and  are  used  to 
record  all  1394  packets  including  PHY,  Primary,  and  Ack  packets. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-47.  The  uPacketType  value  indicates 
the  packet  body  type.  The  uSyncCode  value  is  the  value  of  the  1394  Synchronization  Code 
between  transaction  packets.  The  IEEE  1394  standard  describes  the  Synchronization  Code  as 
“an  application-specific  control  field”,  and  “a  synchronization  point  may  be  the  defined  as 
boundary  between  video  or  audio  frames,  or  any  other  point  in  the  data  stream  the  application 
may  consider  appropriate.”  The  uTransCnt  value  is  the  number  of  separate  transaction 
messages  in  the  data  packet. 


struct  Sul394F0 

{ 

uint32  t 

ChanSpec 

uTransCnt 

:  16; 

// 

Transaction  count 

uint32  t 

Reserved 

:  9; 

uint32  t 

uSyncCode 

:  4; 

// 

Synchronization  code 

uint32  t 

}; 

uPacketType 

:  3; 

// 

Packet  body  type 

Figure  6-47.  Type  0x58  IEEE  1394  Data  Fonnat  0  CSDW. 


Type  0  and  Type  1  data  packets  will  not  have  an  intra-packet  header.  Type  2  data 
packets  will  have  intra-packet  headers  between  transaction  data  messages  with  the  data  packet. 
The  Type  2  intra-packet  header  is  an  8  byte  time  value.  Time  is  represented  in  either  48-bit 
relative  time  format  derived  from  the  RTC  (format  shown  in  Figure  6-5),  or  as  absolute  time.  If 
this  time  is  absolute  time,  it  is  in  either  Chapter  4  weighted  48-bit  time  (format  shown  in 
Figure  6-6)  or  IEEE  1588  time  format  (format  shown  in  Figure  6-7). 

The  IEEE  1394  standards  contain  quite  a  bit  of  example  code  and  data  structures  in 
the  C  language  to  aid  in  data  interpretation. 

Chapter  10  of  IRIG  106-07  (and  prior  editions  of  the  standard)  incorrectly  state  that  Bit  7 
of  the  Packet  Flags  (in  the  packet  header)  is  used  to  determine  if  the  intra-packet  time  is  relative 
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time  or  absolute  time.  The  correct  bit  to  use  is  Bit  6.  This  handbook  is  based  on  (and  correlates 
to)  the  IRIG  106-07  edition;  however  the  "bit  7"  error  will  be  corrected  in  future  releases  of  this 
handbook. 

6.5.36  Type  0x59,  IEEE  1394  Data,  Format  1  (IEEE  1394  Physical  Layer).  IEEE  1394  Data, 
Format  1  packets  are  used  to  record  IEEE  1394  at  the  physical  layer.  All  bus  data  and  bus  events 
can  be  recorded  in  Fonnat  1  packets.  The  IEEE  1394  Data,  Format  0,  Type  2  data  packet 
provides  a  similar  capability  for  capturing  all  bus  traffic  at  the  physical  level.  This  Format  1 
packet  provides  more  status  information,  though,  and  is  preferred  over  the  Format  0,  Type  2  data 
packet. 


The  layout  of  the  CSDW  is  shown  in  Figure  6-48.  The  uPacketCnt  value  indicates  the 
number  of  separate  1394  data  messages  in  the  data  packet. 


struct  Sul394Fl 

{ 

uint32  t 

ChanSpec 

uPacketCnt 

:  16; 

//  Number  of  messages 

uint32  t 

}; 

Reserved 

:  16; 

Figure  6-48.  Type  0x58  IEEE  1394  Data  Fonnat  1  CSDW. 


Individual  1394  data  messages  follow  the  CSDW.  The  format  of  the  intra-packet  data 
header  is  shown  in  Figure  6-49.  The  suIntrPckTime  value  is  an  eight  byte  representation  of 
time  in  either  48-bit  relative  time  format  derived  from  the  RTC  (format  shown  in  Figure  6-5)  ,  or 
as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either  Chapter  4  weighted  48-bit  time 
(format  shown  in  Figure  6-6)  or  IEEE  1588  time  fonnat  (format  shown  in  Figure  6-7).  The 
uDataLength  field  is  the  length  of  the  1394  data  message  in  bytes.  The  bLBO  flag  indicates 
that  some  1394  packets  were  lost  by  the  bus  monitor  due  to  an  overflow  in  the  local  message 
buffer.  The  uTrfOvf  value  indicates  a  1394  transfer  protocol  error.  The  uStatus  field 
indicates  the  value  of  the  eight-bit  Bus  Status  Transfer  from  the  PHY  to  the  link  layer  of  the 
1394  bus.  Bus  Status  Transfers  are  used  to  signal: 

a.  A  Bus  Reset  indication. 

b.  An  Arbitration  Reset  Gap  indication  (both  even  and  odd). 

c.  A  Subaction  Gap  indication. 

d.  A  Cycle  Start  indication  (both  even  and  odd). 


NOTE 

See  IEEE  1394b-2002  Section  17.8  for  more  details  about  interpreting 

r 

uStatus. 
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struct  SuIEEE1394Fl_Header 
{ 


uint64 

t 

suIntraPckTime; 

// 

Reference  time 

uint32 

t 

uDataLength 

16; 

// 

Data  length 

uint32 

t 

Reserved 

1; 

// 

uint32 

t 

bLBO 

1; 

// 

Local  buffer  overflow 

uint32 

t 

uTrfOvf 

2; 

// 

Transfer  overflow 

uint32 

t 

uSpeed 

4; 

// 

Transmission  speed 

uint32 

}; 

t 

uStatus 

8; 

// 

Status  byte 

Figure  6-49.  Type  0x59  IEEE  1394  Data  Format  1  intra-packet  data  header. 

The  complete  1394  bus  data  message  follows  the  intra-packet  data  header.  The  length  of 
the  1394  data  message  is  indicated  in  the  intra-packet  data  header.  If  the  data  length  is  not  a 
multiple  of  four,  the  data  buffer  will  contain  padding  bytes  to  align  the  buffer  on  a  four  byte 
boundary.  The  IEEE  1394  standards  contain  quite  a  bit  of  example  code  and  data  structures  in 
the  C  language  to  aid  in  data  interpretation. 

6.5.37  Type  0x5 A  -  0x5F,  IEEE  1394  Data,  Fonnat  2  -  Fonnat  7.  Reserved  for  future  use. 

6.5.38  Type  0x60,  Parallel  Data,  Format  0.  Parallel  Data,  Format  0  packets  are  used  to  record 
data  bits  received  from  a  discrete  parallel  data  interface.  The  number  of  bits  that  comprise  one 
data  word  can  range  from  2  to  128  bits  in  length.  A  parallel  data  packet  can  contain  multiple 
parallel  data  words 

The  Digital  Cartridge  Recording  System  (DCRsi)  recording  method  and  digital  data 
interface  were  developed  by  Ampex  Data  Systems.  The  DCRsi  tape  recording  method  is  a 
transverse  scan  method  with  the  tape  heads  embedded  in  the  outer  edge  of  a  spinning  disk  placed 
perpendicular  to  the  path  of  the  tape.  Data,  as  recorded  on  the  DCRsi  cartridge,  is  organized  into 
discrete  blocks,  each  assigned  a  unique  address  number  and  time  stamped  as  it  arrives  at  the 
recorder  interface.  The  addressable  block  size  is  4356  bytes.  The  electrical  interface  is  byte¬ 
wide  differential  emitter-coupled  logic  (ECL).  A  simplified  depiction  of  the  interface  is  shown 
in  Figure  6-50. 
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Write  Data 
Write  Clock 
Data  Ready 
Aux  Data 
User  Set 

Read  Data 
Read  Clock 
Data  Valid 
Block  Sync 
Aux  Data  Out 
ECC  Flag 
Butler  Limit 
Transfer  Ready 


RS232/RS242 
Control  Interlace 


Figure  6-50.  DCRsi  interface. 


The  layout  of  the  CSDW  is  shown  in  Figure  6-5 1 .  The  uType  field  indicates  the  type  or 
size  of  parallel  data  stored.  For  values  between  2  and  128,  uType  indicates  the  number  of  bits 
per  parallel  data  word.  The  value  254  indicates  the  parallel  data  is  in  DCRsi  format.  Other 
values  are  reserved.  When  the  data  type  is  not  DCRsi  the  uScanNum  field  is  reserved  and  will 
have  a  value  of  0x00.  When  the  data  type  is  DCRsi,  the  uScanNum  field  contains  the  scan 
number  value  of  the  first  scan  stored  in  the  packet  for  DCRsi  data. 


struct  SuParallelFO  ChanSpec 

{ 

uint32  t 

uScanNum 

:  24; 

// 

Scan 

number 

uint32  t 
} ; 

uType 

:  8; 

// 

Data 

type 

Figure  6-5 1 .  Type  0x60  Parallel  Data  Format  0  CSDW. 


Recorded  parallel  data  follows  the  CSDW.  There  is  no  intra-packet  header.  For  general 
purpose  packets,  bit  padding  is  used  to  align  recorded  data  on  byte  or  word  boundaries.  There  is 
no  count  for  the  number  of  parallel  data  words  following  the  CSDW.  This  must  be  calculated 
from  the  data  length  in  the  header  and  the  number  bytes  per  data  word.  See  the  Chapter  10 
standard  for  complete  details. 
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6.5.39  Type  0x61  -  0x67,  Parallel  Data,  Format  1  -  Format  7.  Reserved  for  future  use. 

6.5.40  Type  0x68,  Ethernet  Data,  Format  0.  Ethernet  Data,  Format  0  packets  are  used  to  record 
Ethernet  data  frames  from  an  Ethernet  network.  In  general,  an  Ethernet  data  packet  will  contain 
multiple  captured  Ethernet  data  frames. 

The  layout  of  the  CSDW  is  shown  in  Figure  6-52.  The  iNumFrames  field  indicates  the 
number  of  Ethernet  frames  included  in  this  data  packet.  The  iFormat  field  indicates  the  format 
of  the  captured  Ethernet  frames.  Format  type  0x00  is  described  in  Chapter  10  as  “Ethernet 
Physical  Layer”  but  in  practice  is  better  described  as  “Ethernet  Data  Link  Layer”  because 
support  for  physical  layer  features  such  as  frame  sync  preamble  and  collision  events  are  not 
described  in  the  Chapter  10  standard. 


struct  SuEthernetF0_ChanSpec 
{ 


uint32 

t 

uNumFrames 

:  16; 

// 

Number 

of 

frames 

uint32 

t 

Reservedl 

:  12; 

uint32 

}; 

t 

uFormat 

:  4; 

// 

Format 

of 

frames 

Figure  6-52.  Type  0x68  Ethernet  Data  Format  0  CSDW. 

Individual  Ethernet  data  messages  follow  the  CSDW.  The  format  of  the  intra-packet  data 
header  is  shown  in  Figure  6-53.  The  suIntrPckTime  value  is  an  eight  byte  representation  of 
time  in  either  48-bit  relative  time  format  derived  from  the  RTC  (format  shown  in  Figure  6-5)  ,  or 
as  absolute  time.  If  this  time  is  absolute  time,  it  is  in  either  Chapter  4  weighted  48-bit  time 
(format  shown  in  Figure  6-6)  or  IEEE  1588  time  format  (format  shown  in  Figure  6-7).  The 
uDataLen  field  is  the  length  of  the  Ethernet  data  in  bytes.  The  uNetID  field  is  used  to 
uniquely  identify  the  physical  network  attachment  point.  The  uSpeed  field  indicates  the  bit  rate 
at  which  the  frame  was  captured  by  the  recorder.  Early  coaxial  cable  based  Ethernet  networks 
(10BASE5  and  10BASE2)  required  all  network  participants  to  operate  at  the  same  bit  rate  since 
they  were  sharing  the  same  physical  channel.  Most  modem  Ethernet  network  topologies 
(10BASE-T,  100BASE-TX,  etc.)  are  a  star  configuration  with  a  single  point  to  point  link 
between  the  networked  device  and  a  network  hub.  In  this  case,  the  network  bit  rate  is  the  bit  rate 
negotiated  between  the  device  (e.g.  the  recorder)  and  the  network  hub.  In  this  star  topology, 
different  devices  can  operate  at  different  bit  rates  on  the  same  Ethernet  network.  The  uSpeed 
field  only  indicates  the  bit  rate  of  the  link  the  data  recorder  has  with  the  network  hub.  It  does  not 
imply  the  speed  of  any  other  devices  on  the  network.  The  uContent  field  indicates  the  type  of 
data  payload.  The  Media  Access  Control  (MAC)  content  type  (0x00)  indicates  Ethernet  Data 
Link  Layer  frames,  including  the  destination  address,  source  address,  type  (in  the  case  of 
Ethernet  II)  or  length  (in  the  case  of  IEEE  802.3),  data,  and  frame  check  sequence.  The  data  link 
frame  preamble  is  not  included,  nor  are  other  features  of  the  physical  layer  such  as  collisions  or 
auto-negotiations.  The  bFrameError  flag  indicates  an  unspecified  error  has  occurred  in  the 
reception  of  the  Ethernet  frame. 
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struct  SuEthernetFO  Header 
{ 


uint64 

t 

suIntraPckTime; 

// 

Reference  time 

uint32 

t 

uDataLen 

14; 

// 

Data  length 

uint32 

t 

Reservedl 

2; 

// 

uint32 

t 

uNetID 

8; 

// 

Network  identifier 

uint32 

t 

uSpeed 

4; 

// 

Ethernet  speed 

uint32 

t 

uContent 

2; 

// 

Captured  data  content 

uint32 

t 

bFrameError 

1; 

// 

Frame  error 

uint32 

t 

Reserved2 

1; 

// 

}  ; 


Figure  6-53.  Type  0x68  Ethernet  Data  Format  0  intra-packet  data  header. 

6.5.41  Type  0x69  -  0x6F,  Ethernet  Data,  Format  1  -  Format  7.  Reserved  for  future  use. 

6.6  Time  Interpretation 

Chapter  10  defines  a  48-bit  Relative  Time  Counter  (RTC)  as  the  basis  for  all  packet  and 
message  time  stamps.  The  RTC  clock  is  10  MHz,  resulting  in  a  clock  resolution  of  100 
nanoseconds.  There  is  no  constraint  on  the  absolute  value  of  the  RTC;  at  recorder  power  on,  it 
could  be  initialized  to  zero  or  some  random  number.  Some  recorder  vendors  will  preset  the  RTC 
to  a  value  based  on  absolute  clock  time,  but  for  interoperability  reasons  it  is  unwise  to  assume 
the  RTC  value  will  be  related  to  absolute  clock  time  in  any  meaningful  fashion. 

Absolute  clock  time  comes  into  a  recorder  and  is  recorded  much  like  any  other  data  source.  In 
fact,  there  may  be  multiple  time  sources  recorded.  Time  Data,  Format  1  data  packets  are  used  to 
record  input  time  signals.  Since  Time  Data,  Format  1  packets  contain  both  the  absolute  input 
time  value  and  the  RTC  clock  value  at  the  instant  the  absolute  time  was  valid,  these  packets  can 
be  used  to  relate  RTC  values  to  the  input  absolute  time  source.  For  example,  if  a  time  packet  is 
recorded  with  a  RTC  value  of  1,000,000  and  an  absolute  time  value  of  100:12:30:25.000,  then 
the  clock  time  of  a  subsequent  data  packet  with  an  RTC  value  of  1,150,000  could  be  deduced  to 
be  100:12:30:25.015  (150,000  clock  tics  x  100  nsec  per  tic  =  15  msec). 

When  multiple  time  channels  are  available,  it  is  incumbent  on  the  programmer  or  data 
analyst  to  determine  and  select  the  best  source  of  time  for  a  particular  data  set.  For  example, 
there  may  be  separate  time  channels  for  time  derived  from  IRIG  B,  Global  Positioning  System 
(GPS),  and  an  internal  battery  backed  up  clock.  In  this  scenario,  all  of  these  time  sources  are 
present  in  the  data  file  as  separate  channels,  each  correlating  the  RTC  to  its  own  notion  of  clock 
time.  The  software  application  may  allow  the  user  to  select  which  source  of  time  to  use  for  a 
given  analysis.  Alternatively,  the  software  may  decide  the  “best”  source  of  time,  depending  on 
which  time  channels  are  providing  valid  time.  In  general,  each  time  source  will  provide  a 
slightly  (or  not  so  slightly)  different  clock  time.  It  is  usually  most  correct  to  select  one  time 
channel  only  and  to  use  this  channel  exclusively  to  correlate  RTC  time  to  absolute  clock  time  for 
all  data  packet  types. 

The  stability  of  the  RTC  isn’t  specified  in  Chapter  10  other  than  to  require  it  to  be  at  least 
as  good  as  a  common  crystal  oscillator.  A  good  grade  crystal  oscillator  can  provide  stability  on 
the  order  of  10  ppm.  Some  vendors  provide  a  RTC  source  considerably  more  stable  than  this.  It 
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is  tempting  for  an  application  to  find  a  single  time  packet  early  in  a  recording  and  to  use  those 
time  values  to  subsequently  derive  clock  time  from  relative  time.  It  is  better  to  use  the  clock  and 
relative  time  values  from  a  time  packet  that  occurs  near  the  current  data  packet  as  the  data  file  is 
decoded  since  there  is  some  drift  in  the  RTC  during  a  recording  session.  It  also  may  be  the  case 
that  there  is  a  jump  in  input  clock  time  during  a  recording,  such  as  when  GPS  locks  for  the  first 
time,  or  when  an  IRIG  time  source  is  reprogrammed. 

6.7  Index  and  Event  Records 

Often  times  it  is  useful  to  make  an  in-memory  version  of  the  data  file  index.  This  allows 
rapid  access  to  recorded  data  packets  based  on  time  or  the  occurrence  of  events.  A  general 
algorithm  for  reading  all  root  and  node  index  packets  is  as  follows: 

1 .  If  "R-x\IDX\E"  is  not  equal  to  "T"  then  index  does  not  exist. 

2.  Move  read  pointer  to  last  packet  of  data  file.  Store  file  offset  of  this  packet. 

3.  If  last  packet  data  type  does  not  equal  0x03  (Computer  Generated  Data,  Format  3) 

then  index  does  not  exist. 

4.  Get  the  index  count  from  the  CSDW. 

5.  For  each  root  index  contained  in  the  packet, 

•  Read  the  Node  Index  offset  value 

•  Move  the  read  pointer  to  the  Node  Index  offset  value 

•  Read  the  Node  Index  packet 

•  Get  the  node  index  count  from  the  CSDW 

•  For  each  node  index  contained  in  the  packet  read  and  store  the  time  stamp, 
channel  ID,  data  type,  and  data  packet  offset  values. 

6.  Read  last  root  node  index.  If  offset  value  is  equal  to  current  root  node  packet  offset 

(stored  in  Step  2)  then  done. 

7.  Else  the  move  read  pointer  to  the  next  Root  Index  packet  offset  value 

8.  Read  the  next  Root  Index  packet. 

9.  Go  to  Step  4. 

6.8  Data  Streaming 

Chapter  10  recorders  can  stream  their  data  over  one  of  their  download  interface  network 
ports  using  User  Datagram  Protocol  (UDP)/IP  and  Chapter  10  UDP  transfer  headers.  This  is 
normally  done  over  an  Ethernet  port,  but  any  network  connection  that  supports  UDP/IP  can  use 
this  method.  The  .  PUBLISH  command  is  used  to  control  data  streaming.  Chapter  6  defines  the 
use  of  .  PUBLISH  and  has  numerous  examples  of  its  use.  Data  can  be  streamed  to  one  or  more 
specific  unicast  and  multicast  IP  addresses,  or  broadcast  address.  Different  channels  can  be 
addressed  to  different  addresses. 

It  is  common  to  publish  different  groups  of  data  to  different  multicast  groups.  According 
to  RFC  3171,  addresses  224.0.0.0  to  239.255.255.255  are  designated  as  multicast  addresses. 
Different  multicast  address  regions  are  designated  for  different  purposes.  According  to  RFC 
2365,  Chapter  10  data  streaming  should  be  directed  to  multicast  addresses  in  the  Local  Scope 
address  range  239.255.0.0  to  239.255.255.255. 
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IP  multicast  packets  are  delivered  by  using  the  Ethernet  MAC  address  range 
0 1 :00:5e:00:00:00  -  01:00:5e:7f:ff:ff.  This  is  23  bits  of  available  address  space.  The  lower 
23  bits  of  the  28-bit  multicast  IP  address  are  mapped  into  the  23  bits  of  available  Ethernet 
address  space.  This  means  that  there  is  ambiguity  in  delivering  packets.  If  two  hosts  on  the 
same  subnet  each  subscribe  to  a  different  multicast  group  whose  address  differs  only  in  the  first 
5  bits,  Ethernet  packets  for  both  multicast  groups  will  be  delivered  to  both  hosts,  requiring  the 
network  software  in  the  hosts  to  discard  the  packets  which  are  not  required.  If  multiple  multicast 
addresses  are  used,  be  careful  to  choose  multicast  addresses  that  will  result  in  different  Ethernet 
multicast  addresses. 

Multicast  data  is  filtered  by  the  Ethernet  controller  hardware,  only  passing  subscribed 
packets  to  the  software  driver  for  decoding.  This  improves  performance  under  high  network 
traffic  loads.  Ethernet  controllers  only  have  a  limited  number  of  multicast  addresses  they  can 
filter.  16  multicast  addresses  is  a  common  hardware  limit.  If  a  workstation  needs  to  subscribe  to 
more  multicast  addresses  than  the  Ethernet  hardware  provides  for,  then  all  multicast  traffic  is 
passed  to  the  software  driver  for  filtering,  negating  the  benefit  of  multicast  filtering  in  hardware. 
The  size  of  a  UDP  packet  is  represented  by  a  16  bit  value  in  the  IPv4  IP  and  UDP  headers,  but 
some  software  implementation  treat  this  as  a  signed  value  with  a  maximum  value  of  2A 1 5  or 
32768.  Because  of  this,  the  maximum  size  of  a  Chapter  10  streaming  packet  should  be  no  more 
than  32724  bytes.  Physical  networks  have  a  Maximum  Transfer  Unit  (MTU),  which  is  the 
largest  data  packet  they  can  carry.  If  a  UDP  packet  has  a  size  larger  than  the  network  MTU,  it 
will  be  fragmented  into  smaller  packets  by  the  IP  software  driver  before  sending  them  over  the 
underlying  physical  network.  The  fragmented  UDP  packets  are  then  reassembled  into  a  larger 
packet  by  the  IP  software  driver  at  the  receiving  end.  There  is  a  performance  penalty  for  this 
fragmentation  and  reassembly.  Better  performance  may  be  achieved  by  choosing  a  UDP  packet 
small  enough  to  avoid  fragmentation  and  reassembly.  Regular  Ethernet  supports  a  maximum 
size  of  1500  bytes  of  data  payload  (IP  header,  UDP  header,  and  UDP  data)  but  some  newer 
Ethernet  technologies  support  larger  jumbo  frames. 

Chapter  10  data  packets  are  sent  in  a  UDP/IP  packet  by  prepending  a  UDP  transfer 
header  to  the  UDP  data  payload.  Chapter  10  data  packet(s)  smaller  than  the  32k  maximum  size 
will  prepend  the  non-segmented  UDP  transfer  header  shown  in  Figure  6-54.  A  Chapter  10  data 
packet  larger  than  the  32k  maximum  size  will  need  to  be  segmented  before  transmission,  and 
will  prepend  the  segmented  UDP  transfer  header  shown  in  Figure  6-55.  IPv6  supports  large  data 
packets,  negating  the  need  for  segmented  data  packets. 


struct  SuUdpTransferHeaderNonseg 
{ 


uint32 

t 

uVersion 

:  4; 

// 

Version 

uint32 

t 

uType 

:  4; 

// 

Type  of  message 

uint32 

}; 

t 

uUdpSeqNum 

:  24; 

// 

UDP  sequence  number 

Figure  6-54.  UDP  Transfer  Header,  non-segmented  data. 
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struct  SuUdpTransf erHeaderSeg 
{ 


uint32 

t 

uVersion 

4; 

// 

Version 

uint32 

t 

uType 

4; 

// 

Type  of 

message 

uint32 

t 

uUdpSeqNum 

24; 

// 

UDP  sequence  number 

uint32 

t 

uChanID 

16; 

// 

Channel 

ID 

uint32 

t 

uChanSeqNum 

8; 

// 

Channel 

sequence  number 

uint32 

t 

uReserved 

8; 

// 

uint32 

}; 

t 

uSegOf f set; 

// 

Segment 

offset 

Figure  6-55.  UDP  Transfer  Header,  segmented  data. 

Computer  Generated  Data,  Format  3  (Recording  Index)  packets  are  meaningless  in  a 
network  data  stream.  It  is  necessary  that  they  be  transmitted  so  that  Channel  ID  0  data  packets 
will  have  contiguous  sequence  numbers  for  error  detection.  They  should  be  ignored,  though, 
when  received. 
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CHAPTER  7 

CONFORMANCE  TO  IRIG  106 

Chapter  10  of  the  IRIG  106  standard  sets  forth  requirements  for  digital  recorders. 
Paragraph  10.3.1  summarizes  requirements  for  a  recorder  to  be  considered  100  percent  compliant 
with  the  standard.  A  number  of  features  described  in  Chapter  10  are  considered  optional. 
Optional  features  are  not  required  to  be  implemented;  however,  if  they  are  implemented,  they 
must  be  in  accordance  with  the  Chapter  10  standard. 

Rather  than  reiterate  all  the  requirements  of  Chapter  10,  Table  7G  and  Table  A2  present 
a  brief  outline  of  the  major  requirement  areas,  as  well  as  those  portions  of  Chapter  10  that  have 
been  identified  as  optional. 
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TABLE  7-1.  PHYSICAL  INTERFACE  REQUIREMENTS 

Physical  Interfaces 

Ch  10  Section 

Required 

Optional 

10.3,  10.4.1 

See  Note 

Recorder  Fibre  Channel 

10.4.2 

s 

Fibre  Channel  SCSI 

10.4.1 

V 

Data  Download 

10.3.11 

S 

Data  streaming 

10.3.8,  10.7 

S 

Configuration  with  TMATS 

10.7.1 

S 

Recorder  Control  and  Status 

10.4.2 

See  Note 

Recorder  IEEE  1394B 

10.4.2.2 

S 

SCSESBP-2 

10.4,  10.9 

a/ 

Data  Download 

10.3.11 

V 

Data  streaming 

10.3.8,  10.7 

V 

Configuration  with  TMATS 

10.7.1 

S 

Recorder  control  and  status 

10.4,  10.4.3 

See  Note 

Recorder  Ethernet  (on  board) 

S 

Data  Download 

10.3.11 

S 

Data  streaming 

10.3.8,  10.7 

Configuration  with  TMATS 

10.7.1 

s 

Recorder  Control  And  Status 

10.3.5,  10.3.6 

s 

Removable  Memory  Media  (RMM) 

10.9.5 

IEEE  1394B  Bilingual  Socket 

10.9 

S 

IEEE  1394B  SCSI/SBP-2 

10.4,  10.9 

V 

Data  Download 

10.3.8,  10.7 

s 

Configuration  with  TMATS 

10.3.2,  10.7.10 

s 

Discrete  Lines 

10.7.10 

S 

Recorder  control  and  status 

10.3.2 

V 

RS-232  and  422  Full  Duplex  Communication 

10.7 

S 

Configuration  with  TMATS 

10.7 

S 

Recorder  Control  And  Status 

10.3 

V 

External  Power  Port 

Note:  Either  Fibre  Channel  or  IEEE  1394B  is  required  for  on-board  recorders;  other  network 
interfaces  are  optional.  Ethernet  is  required  for  ground-based  recorders;  other  network  interfaces 
are  optional. 
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TABLE  7-2.  LOGICAL  INTERFACE  REQUIREMENTS 

Logical  Interfaces 

Ch  10  Section 

Required 

Optional 

10.5 

/ 

Media  File  Interface 

10.5 

S 

Directory  &  File  Table  Entries 

10.3.7 

STANAG  fields  - 

File  Size,  File  Create  Date,  File  Close  Time 

10.6 

Packetization  &  Data  Format 

10.6.1 

V 

Secondary  header 

10.6.1 

S 

Filler  for  packet  length 

10.6.1 

S 

Data  checksum 

10.6.1 

V 

Intrapacket  headers  and  time  stamps 
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APPENDIX  A 

SELECTED  SOURCE  CODE  FILES 

A  software  implementation  of  the  IRIG  106  Chapter  9  and  Chapter  10  standard  is 
available  from  http:Wwww.irigl06.org;  the  software  is  open  source,  meaning  it  is  freely 
available  in  source  code  form.  It  is  written  in  ANSI  C,  and  can  be  compiled  in  GNU  Compiler 
Collection  (GCC)  as  well  as  the  various  Microsoft  Visual  Studio  compiler  suites.  Listed  below 
are  selected  source  files  demonstrating  important  aspects  of  IRIG  106.  These  source  files  are 
also  necessary  for  the  example  programs  in  subsequent  appendices.  This  code  is  under  active 
development.  Go  to  http:Wwww.irigl06.org  for  the  latest  version  of  this  source  code  as  well  as 
additional  source  code  files. 

The  following  source  files  are  shown  in  the  remaining  portions  of  Appendix  A. 


Appendix 

File 

Comments 

A-l 

irigl06chl0.h 

Structures,  macro  definitions,  and  procedures  for 

A-2 

irigl06chl0.c 

opening,  reading/writing,  and  moving  through  an  IRIG 
106  data  file. 

A-3 

i  1 06  time.h 

Structures,  macro  definitions,  and  procedures  for 

A-4 

i  1 06  time.c 

handling  time  in  general 

A-5 

i  1 06_decode_time.h 

Structures,  macro  definitions,  and  procedures  for 
decoding  Time  Data  packets 

A-6 

il06 decode time.c 

A-7 

i  1 06_decode_tmats.h 

Structures,  macro  definitions,  and  procedures  for 
decoding  Computer  Generated  Data,  Format  1 

A-8 

il06 decode tmats.c 

(TMATS  Setup  Record)  packets. 

A-9 

config.h 

Structures  and  macro  definitions  to  provide  portability 
across  supported  compiler  suites. 

A-10 

stdint.h 

Macro  definitions  to  provide  standard  integer  types  of 
specific  sizes  across  supported  compiler  suites. 
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APPENDIX  A-l  -  IRIG106CH10.H 

/**************************************************************************** 

irigl06chl0 . h  - 

Copyright  (c)  2005  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#ifndef  _irigl06chl0_h_ 

#define  _irigl06chl0_h_ 

#ifdef  _ cplusplus 

extern  "C"  { 

#endif 

#include  "config.h" 

/* 

*  Macros  and  definitions 

*  _ 

*/ 


# if  (defined (bTRUE) 

#def  ine 

bTRUE 

(1  = 

=  1) 

#def ine 
#endif 

bFALSE 

(1  = 

=  0) 

#def ine 

MAX  HANDLES 

4 

#def ine 

IRIG106  SYNC 

0xEB25 
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//  Define  the  longest  file  path  string  size 
#undef  MAX_PATH 

#def ine  MAX_PATH  260 

//  Header  and  secondary  header  sizes 
#def ine  HEADERJ3IZE  24 

#def ine  SEC_HEADER_SIZE  12 

//  Header  packet  flags 

#def ine  I106CH10_PFLAGS_CHKSUM_NONE  (uint8_t) 0x00 

#def ine  I106CH10_PFLAGS_CHKSUM_8  (uint8_t) 0x01 

#def ine  I106CH10_PFLAGS_CHKSUM_16  (uint8_t) 0x02 

#def ine  I106CH10_PFLAGS_CHKSUM_32  (uint8_t) 0x03 

#def ine  I106CH10_PFLAGS_OVERFLOW  (uint8_t) 0x10 

#def ine  I106CH10_PFLAGS_TIMESYNCERR  (uint8_t) 0x20 

#def ine  I106CH10_PFLAGS_SEC_HEADER  (uint8_t) 0x80 

//  Header  data  types 

#def ine  I106CH10_DTYPE_COMPUTER_0  (uint8_t) 0x00 

#def ine  I106CH10_DTYPE_USER_DEFINED  (uint8_t) 0x00 

#def ine  I106CH10_DTYPE_COMPUTER_1  (uint8_t) 0x01 

#def ine  I106CH10_DTYPE_TMATS  (uint8_t) 0x01 

#def ine  I106CH10_DTYPE_COMPUTER_2  (uint8_t) 0x02 

#def ine  I106CH10_DTYPE_RECORDING_EVENT  (uint8_t) 0x02 
#def ine  I106CH10_DTYPE_COMPUTER_3  (uint8_t) 0x03 

#def ine  I106CH10_DTYPE_RECORDING_INDEX  (uint8_t) 0x03 
#def ine  I106CH10_DTYPE_COMPUTER_4  (uint8_t) 0x04 

#def ine  I106CH10_DTYPE_COMPUTER_5  (uint8_t) 0x05 

#def ine  I106CH10_DTYPE_COMPUTER_6  (uint8_t) 0x06 

#def ine  I106CH10_DTYPE_COMPUTER_7  (uint8_t) 0x07 

#def ine  I106CH10_DTYPE_PCM_FMT_0  (uint8_t) 0x08 

#def ine  I106CH10_DTYPE_PCM_FMT_1  (uint8_t) 0x09 

#define  I106CH10_DTYPE_PCM  (uint8_t) 0x09  //  Deprecated 

#def ine  I106CH10_DTYPE_IRIG_TIME  (uint8_t) 0x11 

#def ine  I106CH10_DTYPE_1553_FMT_1  (uint8_t) 0x1 9 

#def ine  I106CH10_DTYPE_1553_FMT_2  (uint8_t) OxlA  //  16PP194  Bus 

#def ine  I106CH10_DTYPE_ANALOG  (uint8_t) 0x21 

#def ine  I106CH10_DTYPE_DISCRETE  (uint8_t) 0x2 9 

#def ine  I106CH10_DTYPE_MESSAGE  (uint8_t) 0x30 

#def ine  I106CH10_DTYPE_ARINC_429  (uint8_t) 0x38 

#def ine  I106CH10_DTYPE_VIDEO_FMT_0  (uint8_t) 0x40 

#def ine  I106CH10_DTYPE_VIDEO_FMT_1  (uint8_t) 0x41 

#def ine  I106CH10_DTYPE_VIDEO_FMT_2  (uint8_t) 0x42 

#def ine  I106CH10_DTYPE_IMAGE_FMT_0  (uint8_t) 0x48 

#def ine  I106CH10_DTYPE_IMAGE_FMT_1  (uint8_t) 0x4 9 

#def ine  I106CH10_DTYPE_UART_FMT_0  (uint8_t) 0x50 

#def ine  I106CH10_DTYPE_1394_FMT_0  (uint8_t) 0x58 

#def ine  I106CH10_DTYPE_1394_FMT_1  (uint8_t) 0x59 

#def ine  1 1 0 6CH1 0_DTYPE_PARALLEL_FMT_0  (uint8_t) 0x60 

#def ine  1 1 0 6CH1 0_DTYPE_ETHERNET_FMT  0  (uint8  t) 0x68 


III  Error  return  codes 
typedef  enum 
{ 

I106JDK 

110  6_OPEN_ERROR 
110  6_OPEN_WARNING 
I106_EOF 
I106_BOF 
110  6_READ_ERROR 
110  6_WRI TE_ERROR 
110  6_MORE_DATA 
1106  SEEK  ERROR 


0,  ///<  Everything  okey  do key 

1,  ///<  Fatal  problem  opening  for  read  or  write 

2,  ///<  Non-fatal  problem  opening  for  read  or  write 

3,  ///<  End  of  file  encountered 

4,  // 

5,  ///<  Error  reading  data  from  file 

6,  ///<  Error  writing  data  to  file 

7,  // 

8, 
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1106  WRONG  FILE  MODE 

=  9, 

1106  NOT  OPEN 

=  10, 

1106  ALREADY  OPEN 

=  11, 

1106  BUFFER  TOO  SMALL 

=  12, 

1106  NO  MORE  DATA 

=  13, 

1106  NO  FREE  HANDLES 

=  14, 

1106  INVALID  HANDLE 

LO 
\ — 1 

II 

1106  TIME  NOT  FOUND 

=  16, 

1106  HEADER  CHKSUM  BAD 

=  17, 

1106  NO  INDEX 

00 
\ — 1 

II 

1106  UNSUPPORTED 
}  EnI106Status; 

=  19, 

III  Data  file  open  mode 
typedef  enum 
{ 

I106_READ 

I106JDVERWRITE 

I106_APPEND 

110  6_READ_IN_ORDER 

}  EnI106Chl0Mode; 


1,  //  Open  existing  file  for  reading 

2,  //  Create  new  file  or  overwrite  an  exising  file 

3,  //  Append  data  to  the  end  of  an  existing  file 

4,  //  Open  existing  file  for  reading  in  time  order 


III  Read  state  is  used  to  keep  track  of  the  next  expected  data  file  structure 


typedef  enum 

{ 

enclosed  =  0, 
enWrite  =  1, 
enReadUnsynced  =  2, 
enReadHeader  =  3, 
enReadData  =  4, 
}  EnFileState; 


III  Index  sort  state 
typedef  enum 
{ 

enUnsorted  =  0, 
enSorted  =  1, 
enSortError  =  2, 
}  EnSortStatus ; 


/* 

*  Data  structures 

~k _ 

*/ 

#if  defined (_MSC_VER) 

#pragma  pack (push) 

#pragma  pack(l) 
fendif 

III  IRIG  106  header  and  optional  secondary  header  data  structure 
typedef  PUBLIC  struct  SuI106Chl0Header_S 
{ 


uintl6  t 

uSync; 

///<  Packet  Sync  Pattern 

uintl6  t 

uChID; 

///<  Channel  ID 

uint32  t 

ulPacketLen; 

///<  Total  packet  length 

uint32  t 

ulDataLen; 

///<  Data  length 

uint8  t 

ubyHdrVer ; 

///<  Header  Version 

uint8  t 

ubySeqNum; 

///<  Sequence  Number 

uint8  t 

ubyPacketFlags ; 

///<  PacketFlags 

uint8  t 

ubyDataType; 

///<  Data  type 

uint8  t 

aubyRefTime [ 6] ; 

///<  Reference  time 
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uintl6  t 

uChecksum; 

///< 

Header  Checksum 

uint32  t 

aulTime [2]  ; 

///< 

Time  (start  secondary  header) 

uintl6  t 

uReserved; 

II 

uintl6  t 

uSecChecksum; 

///< 

Secondary  Header  Checksum 

! defined ( 

GNUC  ) 

}  SuI106Chl0Header ; 

#else 

}  _ attribute _  ((packed))  SuI106Chl0Header ; 

#endif 


//  Structure  for  holding  file  index 
typedef  struct 
{ 

int64_t  llOffset; 

int64_t  UTime; 

}  SuFilelndex; 


//  Various  file  index  array  indexes 
typedef  struct 
{ 


EnSortStatus 

SuFilelndex 

int 

int 

int 


int64_t 

int 

}  Sulndex; 


enSortStatus ; 

*  asulndex; 
iArraySize; 
iArrayUsed; 

iArrayCurr;  //  Current 
UNextReadOf  f  set  ; 
iNumSear chSteps ; 


position 


in 


index  array 


III  Data  structure 
typedef  struct 
{ 

int 

int 

char 

EnI106Chl0Mode 
EnFileState 
Sulndex 
unsigned  long 
unsigned  long 
unsigned  long 
unsigned  long 
unsigned  long 
char 


for  IRIG  106  read/write 


blnUse; 

iFile; 

szFileName [MAX_PATH]  ; 
enFileMode ; 
enFileState; 
sulndex; 

ulCurrPacketLen; 
ulCurrHeaderBuffLen; 
ulCurrDataBuffLen; 
ulCurrDataBuf f ReadPos ; 
ulTotalBytesWr itten; 
achReserve [128 ] ; 


}  SuI106Chl0Handle; 


handle 


#if  defined (_MSC_VER) 
#pragma  pack (pop) 
#endif 


/* 

*  Global  data 


*/ 

extern  SuI106Chl0Handle  g_sul 10 6Handle [ 4 ] ; 


/* 
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*  Function  Declaration 


*/ 

//  Open  /  Close 

EnI106Status  I106_CALL_DECL 

enI106ChlOOpen  (int 

const  char 
EnI106Chl0Mode 


EnI106Status  I106_CALL_DECL 

enI106Ch!0Close  (int 


*  piI106Chl0Handle, 
szOpenFileName [ ] , 
enMode) ; 


iI106Handle) ; 


//  Read  /  Write 
// - 


EnI106Status  I106_CALL_DECL 

enI106Chl0ReadNextHeader (int 

SuI106Chl OHeader 


iI106Chl OHandle, 
psuI106Hdr) ; 


EnI106Status  I106_CALL_DECL 

enI106Chl0ReadNextHeaderFile (int  iHandle, 

SuI106Chl0Header  *  psuHeader) ; 


EnI106Status  I106_CALL_DECL 

enI106ChlOReadNextHeaderInOrder (int  iHandle, 

SuI106Chl0Header  *  psuHeader) ; 

EnI106Status  I106_CALL_DECL 

enI106Chl0ReadPrevHeader (int  iI106Chl0Handle, 

SuI106Chl0Header  *  psuI106Hdr) ; 


EnI106Status  I106_CALL_DECL 
enI106Chl0ReadData (int 

unsigned  long 
void 


ill06Chl OHandle, 
ulBuf f Size, 

*  pvBuff) ; 


EnI106Status  I106_CALL_DECL 
enI106Chl0WriteMsg (int 

SuI106Chl OHeader 
void 


iI106Chl OHandle, 

*  psuI106Hdr, 

*  pvBuff) ; 


//  Move  file  pointer 
// - 

EnI106Status  I106_CALL_DECL 

enI106Chl0FirstMsg (int  iI106Chl0Handle) ; 

EnI106Status  I106_CALL_DECL 

enll 06Chl0LastMsg ( int  iI106Chl0Handle)  ; 

EnI106Status  I106_CALL_DECL 

enI106Chl0SetPos (int  iI106Chl0Handle,  int64_t  llOffset) ; 
EnI106Status  I106_CALL_DECL 

enI106Chl0GetPos (int  iI106Chl0Handle,  int64_t  *  pllOffset)  ; 

//  Utilities 
// - 
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int  I106_CALL_DECL 

iHeaderlnit (SuI106Chl0Header  * 
unsigned  int 
unsigned  int 
unsigned  int 
unsigned  int 


psuHeader , 
uChanID, 
uDataType, 
uFlags, 
uSeqNum) ; 


int  110  6_CALL_DECL 

iGetHeaderLen (SuI106Chl0Header  *  psuHeader); 


uint32_t  I106_CALL_DECL 

uGetDataLen (SuI106Chl0Header  *  psuHeader); 


uintl 6_t  110  6_CALL_DECL 

uCalcHeaderChecksum (SuI106Chl0Header  *  psuHeader); 


uintl 6_t  I106_CALL_DECL 

uCalcSecHeaderChecksum (SuI106Chl0Header  *  psuHeader); 


uint32_t  110  6_CALL_DECL 

uCalcDataBuf fReqSize (uint32_t  uDataLen,  int  iChecksumType) ; 

EnI106Status  I106_CALL_DECL 

uAddDataFillerChecksum (SuI106Chl0Header  *  psuI106Hdr, 

unsigned  char  achData [ ] ) ; 


//  In-order  indexing 
// - 

void  110  6_CALL_DECL 

vMakelnOrder Index ( int  iHandle) ; 

int  I106_CALL_DECL 

bReadlnOrder Index ( int  iHandle,  char  *  szIdxFileName) ; 
int  I106_CALL_DECL 

bWritelnOrderlndex ( int  iHandle,  char  *  szIdxFileName); 

#ifdef  _ cplusplus 

} 

#endif 

#endif 


A- 1-6 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


APPENDIX  A-2  -  IRIG106CH10.C 

/**************************************************************************** 

irigl06chl0 . c  - 

Copyright  (c)  2005  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <string.h> 

#include  <fcntl.h> 

#include  <sys/types . h> 

#include  <sys/stat.h> 

#if  defined (_WIN32 ) 

#include  <io.h> 

#endif 


#include  "config.h" 
#include  "stdint.h" 

#include  "irigl06chl0.h" 
#include  "il06_time.h" 

/* 

*  Macros  and  definitions 

*  _ 

*/ 
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/* 

*  Data  structures 


*/ 


/* 

struct  SuInOrderHdrlnf o 


SuI106Chl0Header 
struct  SuInOrderHdrlnf o 
struct  SuInOrderHdrlnf o 


suHdr ; 

*  psuNext; 

*  psuPrev; 


*/ 


/* 

*  Module  data 


*/ 


SuI106Chl0Handle  g_sull 06Handle [MAX_HANDLES ] ; 
static  int  m  bHandlesInited  =  bFALSE; 


//  In  order  read  linked 
/* 

struct  SuInOrderHdrlnf o 
struct  SuInOrderHdrlnf o 
struct  SuInOrderHdrlnf o 

struct  SuInOrderHdrlnf o 
*/ 

/* 

*  Function  Declaration 


*/ 


list  pointers 

*  m_psuFir stlnOrderHdr 

*  m_psuLastInOrderHdr 

*  m_psuCurrInOrderHdr 

*  m_psuFir stlnOrderFree 


NULL; 

NULL; 

NULL; 

NULL; 


#ifdef  LOOK-AHEAD 

void  vCheckFillLookAheadBuf f er (int  iHandle) ; 
#endif 


/* 


*/ 


EnI106Status  1106  CALL  DECL 


enI106ChlOOpen (int 

const  char 


EnI106Chl0Mode 


*  piHandle, 
szFileName [ ] , 
enMode) 


rnt 

int 

int 

uintl6— t 

EnI106Status 

SuI106Chl0Header 


iReadCnt ; 
ildx; 
iFlags ; 
uSignature ; 
enStatus ; 
suI106Hdr; 


//  Initialize  handle  data  if  necessary 
if  (m_bHandlesInited  ==  bFALSE) 

{ 

for  (ildx=0;  i I dx<MAX_HANDLE  S ;  ildx+  +  ) 

g_suI106Handle [ildx] .blnUse  =  bFALSE; 
m_bHandlesInited  =  bTRUE; 

}  //  end  if  file  handles  not  inited  yet 
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//  Get  the  next  available  handle 
*piHandle  =  -1; 

for  (ildx=0;  iIdx<MAX_HANDLES;  ildx++) 

{ 

if  (g_suI106Handle [ildx] .blnUse  ==  bFALSE) 

{ 

g_suI106Handle [ildx] .blnUse  =  bTRUE; 

*piHandle  =  ildx; 
break; 

}  //  end  if  unused  handle  found 
}  //  end  looking  for  unused  handle 

if  (*piHandle  ==  -1) 

{ 

return  110  6_NO_FREE_HANDLES ; 

}  //  end  if  handle  not  found 

//  Initialize  some  data 

g_suI106Handle [*piHandle] . enFileState  =  enclosed; 
g_suI106Handle [*piHandle] . sulndex. enSortStatus  =  enUnsorted; 

//  Get  a  copy  of  the  file  name 

strncpy  (g_sul 10 6Handle [ *piHandle] . szFileName,  szFileName, 
sizeof (g_suI106Handle [*piHandle] . szFileName) ) ; 
g_suI106Handle [*piHandle] . szFileName [ sizeof (g_sul 10 6Handle [ *piHandle] .szFileName)  -  1] 

-  '  \  0  '  ; 

//  Reset  total  bytes  written 

g_suI106Handle [*piHandle] . ulTotalBytesWr itten  =  0L; 

/***  Read  Mode  ***/ 

//  Open  for  read 

if  ( (I106_READ  ==  enMode)  ||  (110  6_READ_IN_ORDER  ==  enMode) ) 

{ 

////  Try  to  open  file 
#if  defined (_MSC_VER) 

iFlags  =  0_RD0NLY  |  0_BINARY; 

#elif  defined ( _ GCC _ ) 

iFlags  =  0_RD0NLY  |  0_LARGEFILE; 

#else 

iFlags  =  0_RD0NLY; 

#endif 

g_suI106Handle [*piHandle] . iFile  =  open ( szFileName,  iFlags,  0) ; 
if  (g_suI106Handle [*piHandle] . iFile  ==  -1) 
return  I106_OPEN_ERROR; 

////  Check  to  make  sure  it  is  a  valid  IRIG  106  Ch  10  data  file 
//  Check  for  valid  signature 

//  If  we  couldn't  even  read  the  first  2  bytes  then  return  error 
iReadCnt  =  read (g_suI106Handle [*piHandle] . iFile,  SuSignature,  2); 
if  (iReadCnt  !=  2) 

{ 

close (g_suI106Handle [*piHandle] . iFile) ; 
return  Il06_OPEN_ERROR; 

} 

//  If  the  first  word  isn't  the  sync  value  then  return  error 
if  (uSignature  !=  IRIG106_SYNC) 
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{ 

close (g_suI106Handle [*piHandle] . iFile) ; 
return  I106_OPEN_ERROR; 

} 


////  Reading  data  file  looks  OK  so  check  some  other  stuff 

//  Open  OK  and  sync  character  OK  so  set  read  state  to  reflect  this 
g_suI106Handle [*piHandle] . enFileState  =  enReadHeader; 

//  Make  sure  first  packet  is  a  config  packet 
enI106Chl0SetPos (*piHandle,  0L) ; 

enStatus  =  enI106Chl0ReadNextHeaderFile (*piHandle,  &suI106Hdr) ; 
if  (enStatus  !=  I106JOK) 

return  I106_OPEN_WARNING; 

if  ( sull 06Hdr . ubyDataType  !=  I106CH10_DTYPE_COMPUTER_1) 
return  1106  OPEN  WARNING; 


//  Everything  OK  so  get  time  and  reset  back  to  the  beginning 
//  f seek (g_sull 06Handle [ *piHandle ] . pFile,  0L,  SEEK_SET) ; 

enI106Chl0SetPos (*piHandle,  0L)  ; 

g_suI106Handle [*piHandle] . enFileState  =  enReadHeader; 
g_suI106Handle [*piHandle] . enFileMode  =  enMode; 

if  (110  6_READ_IN_ORDER  ==  enMode) 

g_suI106Handle [*piHandle] . sulndex. iArrayCurr  =  0; 

}  //  end  if  read  mode 


/***  Overwrite  Mode  ***/ 

//  Open  for  overwrite 

else  if  (I106JOVERWRITE  ==  enMode) 

{ 

III  Try  to  open  file 
#if  defined (_MSC_VER) 

iFlags  =  0_WRONLY  |  0_CREAT  |  0_BINARY; 

#elif  defined ( _ GCC _ ) 

iFlags  =  0_WRONLY  |  0_CREAT  |  0_LARGEFILE; 

#else 

iFlags  =  0_WRONLY  |  0_CREAT; 

#endif 

g_suI106Handle [*piHandle] . iFile  =  open ( szFileName,  iFlags,  _S_IREAD  | 
if  (g_suI106Handle [*piHandle] . iFile  ==  -1) 
return  I106_OPEN_ERROR; 

//  Open  OK  and  write  state  to  reflect  this 
g_suI106Handle [*piHandle] . enFileState  =  enWrite; 
g_suI106Handle [*piHandle] . enFileMode  =  enMode; 

}  //  end  if  read  mode 


/***  Any  other  mode  is  an  error  ***/ 
else 

{ 

return  I106_OPEN_ERROR; 

} 

return  1106  OK; 


S_IWRITE) 
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/* 


*/ 


EnI106Status  I106_CALL_DECL 

enI106Chl0Close (int  iHandle) 

{ 

//  If  handles  have  been  init'ed  then  bail 
if  (m_bHandlesInited  ==  bFALSE) 
return  I106_NOT_OPEN; 

//  Check  for  a  valid  handle 
if  ( (iHandle  <  0)  II 

(iHandle  >  MAX_HANDLES)  | | 

(g_suI106Handle [iHandle] .blnUse  ==  bFALSE)) 

{ 

return  110  6_INVALI D_HANDLE ; 

} 

//  Make  sure  the  file  is  really  open 
if  ( (g_suI106Handle [iHandle] . iFile  !  =  -1)  && 
(g_suI106Handle [iHandle] .blnUse  ==  bTRUE) ) 
{ 

//  Close  the  file 

close (g_suI106Handle [iHandle] .iFile) ; 

} 


NULL; 

0; 

0; 

0; 

enUnsorted; 

//  Reset  some  status  variables 
g_suI106Handle [iHandle] . iFile  =  -1; 

g_sull 06Handle [ iHandle ]. blnUse  =  bFALSE; 

g_suI106Handle [iHandle] . enFileState  =  enclosed; 

return  I106_OK; 

} 


//  Free  index  buffer  and  mark  unsorted 
free (g_sul 10  6Handle [ iHandle]  . sulndex . a su Index) ; 
g_sull 06Handle [ iHandle ] . sulndex. asulndex  = 

g_suI106Handle [iHandle] . sulndex. iArraySize  = 

g_suI106Handle [iHandle] . sulndex . iArrayUsed  = 

g_suI106Handle [iHandle] . sulndex . iNumSearchSteps  = 
g_suI106Handle [iHandle] . sulndex . enSortStatus  = 


/*  -  */ 

//  Get  the  next  header.  Depending  on  how  the  file  was  opened  for  reading, 

//  call  the  appropriate  routine. 

EnI106Status  I106_CALL_DECL 

enI106Chl0ReadNextHeader (int  iHandle, 

SuI106Chl0Header  *  psuHeader) 

{ 

EnI106Status  enStatus; 

switch  (g_suI106Handle [iHandle] .enFileMode) 

{ 

case  110 6_READ  ; 

enStatus  =  enI106Chl0ReadNextHeaderFile (iHandle,  psuHeader); 
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break; 

case  110 6_READ_I N_ORDER  : 

if  (g_sull 06Handle [iHandle ] . sulndex . enSortStatus  ==  enSorted) 

enStatus  =  enI106ChlOReadNextHeaderInOrder (iHandle,  psuHeader); 

else 

enStatus  =  enI106Chl0ReadNextHeaderFile (iHandle,  psuHeader); 
break; 

default  : 

enStatus  =  I106_WRONG_FILE_MODE; 
break; 

}  //  end  switch  on  read  mode 

return  enStatus; 

} 


/*  -  */ 

//  Get  the  next  header  in  the  file  from  the  current  position 
EnI106Status  I106_CALL_DECL 

enI106Chl0ReadNextHeaderFile (int  iHandle, 

SuI106Chl0Header  *  psuHeader) 

{ 


int 

iReadCnt ; 

int 

bReadHeaderWasOK 

int64  t 

USkipSize; 

int64  t 

HFileOf  fset; 

EnI106Status 

enStatus ; 

//  Check  for 

a  valid  handle 

if  ( (iHandle 

<  0)  II 

(iHandle  >  MAX_HANDLES)  | | 

(g_suI106Handle [iHandle] .blnUse  ==  bFALSE) ) 

{ 

return  110  6_INVALI D_HANDLE ; 

} 

//  Check  file  state 

switch  (g_suI106Handle [iHandle] . enFileState) 

{ 

case  enclosed  : 

return  I106_NOT_OPEN; 
break; 

case  enWrite  : 

return  I106_WRONG_FILE_MODE; 
break; 

case  enReadHeader  : 
break; 

case  enReadData  : 

USkipSize  =  g_suI106Handle [iHandle] . ulCurrPacketLen  - 

g_suI106Handle [iHandle] . ulCurrHeaderBuf fLen  - 
g_suI106Handle [ iHandle] . ulCurrDataBuffReadPos; 
enStatus  =  enI106Chl0GetPos (iHandle,  sllFileOff set) ; 
if  (enStatus  !=  I106_OK) 

return  1106  SEEK  ERROR; 
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HFileOffset  +=  USkipSize; 

enStatus  =  enI106Chl0SetPos (iHandle,  HFileOf fset)  ; 
if  (enStatus  !=  I106_OK) 

return  I106_SEEK_ERROR; 

break; 

case  enReadUnsynced  : 
break; 

}  //  end  switch  on  file  state 

//  Now  we  might  be  at  the  beginning  of  a  header.  Read  what  we  think 
//  is  a  header,  check  it,  and  keep  reading  if  things  don't  look  correct. 
bReadHeaderWasOK  =  bTRUE; 
while  (bTRUE) 

{ 

//  Read  the  header 

iReadCnt  =  read (g_suI106Handle [iHandle] . iFile,  psuHeader,  HEADER_SIZE) ; 

//  Keep  track  of  how  much  header  we've  read 
g_suI106Handle [iHandle] . ulCurrHeaderBuf fLen  =  HEADER_SIZE; 

//  If  there  was  an  error  reading,  figure  out  why 
if  (iReadCnt  !=  HEADERJ3IZE) 

{ 

g_suI106Handle [iHandle] . enFileState  =  enReadUnsynced; 
if  (iReadCnt  ==  -1) 

return  110  6_RE AD_E  RROR ; 

else 

return  I106_EOF; 

}  //  end  if  read  error 

//  Setup  a  one  time  loop  to  make  it  easy  to  break  out  if 
//  there  is  an  error  encountered 
do 

{ 

//  Read  OK,  check  the  sync  field 
if  (psuHeader->uSync  !=  IRIG106_SYNC) 

{ 

g_suI106Handle [iHandle] . enFileState  =  enReadUnsynced; 

bReadHeaderWasOK  =  b FALSE; 

break; 

} 

//  Always  check  the  header  checksum 

if  (psuHeader->uChecksum  !=  uCalcHeaderChecksum (psuHeader ) ) 

{ 

//  If  the  header  checksum  was  bad  then  set  to  unsynced  state 
//  and  return  the  error.  Next  time  we're  called  we'll  go 
//  through  lots  of  heroics  to  find  the  next  header, 
if  (g_suI106Handle [iHandle] . enFileState  !=  enReadUnsynced) 

r 

g_suI106Handle [iHandle] . enFileState  =  enReadUnsynced; 
return  110  6_HEADER_CHKSUM_BAD ; 

} 

bReadHeaderWasOK  =  b FALSE; 
break; 

} 

//  MIGHT  NEED  TO  CHECK  HEADER  VERSION  HERE 
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//  Header  seems  OK  at  this  point 

//  Figure  out  if  there  is  a  secondary  header 

if  ( (psuHeader->ubyPacketFlags  &  I106CH10_PFLAGS_SEC_HEADER)  !=  0) 

{ 

//  Read  the  secondary  header 

iReadCnt  =  read (g_sull 06Handle [ iHandle] . iFile, 

&psuHeader->aulTime [ 0 ]  ,  SEC_HEADER_SIZE) ; 

//  Keep  track  of  how  much  header  we've  read 

g_sull 06Handle [ iHandle ] . ulCurrHeaderBuf fLen  +=  SEC_HEADER_SIZE; 

//  If  there  was  an  error  reading,  figure  out  why 
if  (iReadCnt  !=  HEADERJ3IZE) 

{ 

g_suI106Handle [iHandle] . enFileState  =  enReadUnsynced; 
if  (iReadCnt  ==  -1) 

return  110  6_RE AD_E  RROR ; 

else 

return  I106_EOF; 

}  //  end  if  read  error 

//  Always  check  the  secondary  header  checksum  now 
if  (psuHeader->uChecksum  !=  uCalcSecHeaderChecksum (psuHeader ) ) 

{ 

//  If  the  header  checksum  was  bad  then  set  to  unsynced  state 
//  and  return  the  error.  Next  time  we're  called  we'll  go 
//  through  lots  of  heroics  to  find  the  next  header, 
if  (g_sull 06Handle [iHandle] . enFileState  !=  enReadUnsynced) 

{ 

g_sull 06Handle [iHandle] . enFileState  =  enReadUnsynced; 
return  110  6_HEADER_CHKSUM_BAD ; 

} 

bReadHeaderWasOK  =  b FALSE; 
break; 

} 


}  //  end  if  secondary  header 

}  while  (bFALSE) ;  //  end  one  time  error  testing  loop 

//  If  read  header  was  OK  then  break  out 
if  (bReadHeaderWasOK  ==  bTRUE) 
break; 


//  Read  header  was  not  OK  so  try  again  4  bytes  beyond  previous  read  point 
enStatus  =  enI106Chl0GetPos (iHandle,  sllFileOff set)  ; 
if  (enStatus  !=  I106_OK) 

return  1106  SEEK  ERROR; 


HFileOffset  =  HFileOffset  -  g_suI106Handle [iHandle] . ulCurrHeaderBuf fLen  +  1; 

enStatus  =  enI106Chl0SetPos (iHandle,  HFileOf fset) ; 
if  (enStatus  !=  I106_OK) 

return  1106  SEEK  ERROR; 


}  //  end  while  looping  forever,  looking  for 
//  Save  some  data  for  later  use 

g_suI106Handle [iHandle] . ulCurrPacketLen  = 
g_suI106Handle [iHandle] . ulCurrDataBuf f Len  = 
g_sull 06Handle [ iHandle ] . ulCurrDataBuf fReadPos  = 
g_sull 06Handle [ iHandle ] .enFileState  = 


a  good  header 

psuHeader->ulPacketLen; 
uGetDataLen (psuHeader)  ; 

0; 

enReadData; 
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return  I106_OK; 

}  //  end  enI106Chl0ReadNextHeaderFile ( ) 


/*  -  */ 

//  Get  the  next  header  in  time  order  from  the  file 


EnI106Status  I106_CALL_DECL 

enll 0 6 ChlOReadNext Header InOrder ( int 

SuI106Chl0Header 


{ 


iHandle, 

*  psuHeader) 


Sulndex 

EnI106Status 

int64_t 

EnFileState 


*  psulndex  =  &g_sull 06Handle [ iHandle] . sulndex; 
enStatus ; 
llOf fset; 
enSavedFileState; 


//  If  we're  at  the  end  of  the  list  then  we  are  at  the  end  of  the  file 
if  (psuIndex->iArrayCurr  ==  psuIndex->iArrayUsed) 
return  I106_EOF; 

//  Save  the  read  state  going  in 

enSavedFileState  =  g_suI106Handle [iHandle] . enFileState; 

//  Move  file  pointer  to  the  proper,  er,  point 

llOffset  =  psulndex->asulndex [psuIndex->iArrayCurr ]. llOffset; 

enStatus  =  enI106Chl0SetPos (iHandle,  llOffset); 

//  Go  ahead  and  get  the  next  header 

enStatus  =  enI106Chl0ReadNextHeaderFile (iHandle,  psuHeader); 

//  If  the  state  was  unsynced  before  but  is  synced  now,  figure  out  where  in  the 
//  index  we  are 

if  ( (enSavedFileState  ==  enReadUnsynced)  && 

(g_sul 10 6Handle [ iHandle] . enFileState  !=  enReadUnsynced)) 

{ 

enI106Chl0GetPos (iHandle,  sllOffset) ; 
llOffset  -=  iGetHeaderLen (psuHeader ) ; 
psuIndex->iArrayCurr  =  0; 

while  (psuIndex->iArrayCurr  <  psuIndex->iArrayUsed) 

{ 

if  (llOffset  ==  psulndex->asulndex [psuIndex->iArrayCurr ]. llOffset) 
break; 

psuIndex->iArrayCurr++ ; 

} 

//  if  psuIndex->iArrayCurr  ==  psuIndex->iArrayUsed  then  bad  things  happened 

} 


//  Move  array  index  to  the  next  element 
psuIndex->iArrayCurr++ ; 

return  enStatus; 

}  //  end  enI106ChlOReadNextHeader!nOrder ( ) 


/* 


*/ 


EnI106Status  I106_CALL_DECL 

enI106Chl0ReadPrevHeader (int 


iHandle, 
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{ 

int 

int 

int64_t 

int64_t 

EnI106Status 


SuI106Chl0Header  *  psuHeader) 

bFound; 
iReadCnt ; 

USkipSize; 

HCurrPos  ; 
enStatus ; 


//  Check  for  a  valid  handle 
if  ( (iHandle  <  0)  II 

(iHandle  >  MAX_HANDLES)  | | 

(g_suI106Handle [iHandle] .blnUse  ==  bFALSE) ) 

{ 

return  110  6_INVALI D_HANDLE ; 

} 


//  Check  file  mode 

switch  (g_suI106Handle [iHandle] . enFileState) 

{ 

case  enclosed  : 

return  I106_NOT_OPEN; 
break; 

case  enWrite  : 

return  I106_WRONG_FILE_MODE; 
break; 

case  enReadHeader  : 
case  enReadData  : 

//  Backup  to  a  point  just  before  the  most  recently  read  header. 

//  The  amount  to  backup  is  the  size  of  the  previous  header  and  the  amount 
//  of  data  already  read. 

USkipSize  =  g_suI106Handle [iHandle] . ulCurrHeaderBuf f Len  + 
g_suI106Handle [ iHandle] . ulCurrDataBuf f ReadPos ; 

//  Now  to  save  some  time  backup  more,  at  least  the  size  of  a  header  with  no  data 
USkipSize  +=  HEADERJ3IZE; 

break; 

case  enReadUnsynced  : 

USkipSize  =  4; 

break; 

}  //  end  switch  file  state 


//  Figure  out  where  we're  at  and  where  in  the  file  we  want  to  be  next 
enI106Chl0GetPos  (iHandle,  &HCurrPos)  ; 

//  If  unsynced  then  make  sure  we  are  on  a  4  byte  offset 
if  (g_suI106Handle [iHandle] . enFileState  ==  enReadUnsynced) 

USkipSize  =  USkipSize  -  (HCurrPos  %  4); 

HCurrPos  -=  USkipSize; 

//  Now  loop  forever  looking  for  a  valid  packet  or  die  trying 
bFound  =  bFALSE; 
while  (bTRUE) 

{ 

//  Go  to  the  new  position  and  look  for  a  legal  header 
enStatus  =  enI106Chl0SetPos (iHandle,  HCurrPos) ; 
if  (enStatus  !=  1106  OK) 
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return  I106J3EEK_ERROR; 

//  Read  and  check  the  header  sync 

iReadCnt  =  read (g_suI106Handle [iHandle] . iFile,  & (psuHeader->uSync) ,  2); 
if  (iReadCnt  !=  2) 

return  I106_SEEK_ERROR; 
if  (psuHeader->uSync  !=  IRIG106_SYNC) 
continue ; 

//  Sync  pattern  matched  so  check  the  header  checksum 

iReadCnt  =  read (g_suI106Handle [iHandle] . iFile,  & (psuHeader->uChID) ,  HEADER_SI ZE-2 ) 
if  (iReadCnt  !=  HEADERJ3IZE-2) 
return  I106_SEEK_ERROR; 

if  (psuHeader->uChecksum  ==  uCalcHeaderChecksum (psuHeader ) ) 

{ 

bFound  =  bTRUE; 
break; 

} 

//No  match,  go  back  4  more  bytes  and  try  again 
HCurrPos  -=  4; 

//  Check  for  begining  of  file 
if  (HCurrPos  <  0) 

{ 

return  I106_BOF; 

} 


}  //  end  looping  forever 

//  If  good  header  found  then  go  back  to  just  before  the  header 
//  and  call  GetNextHeader ( )  to  let  it  do  all  the  heavy  lifting, 
if  (bFound  ==  bTRUE) 

{ 

enStatus  =  enI106Chl0SetPos (iHandle,  HCurrPos) ; 
if  (enStatus  !=  I106_OK) 

return  I106_SEEK_ERROR; 

g_suI106Handle [iHandle] . enFileState  =  enReadHeader ; 
enStatus  =  enI106Chl0ReadNextHeader (iHandle,  psuHeader); 

} 


return  enStatus; 

}  //  end  enI106Chl0ReadPrevHeader ( ) 


/*  -  */ 

EnI106Status  I106_CALL_DECL 
enI106Chl0ReadData (int 

unsigned  long 
void 

{ 

int  iReadCnt; 

unsigned  long  ulReadAmount ; 

//  Check  for  a  valid  handle 
if  ( (iHandle  <  0)  II 

(iHandle  >  MAX_HANDLES)  | | 

(g_suI106Handle [iHandle] .blnUse  ==  bFALSE) ) 

{ 

return  110  6_INVALI D_HANDLE ; 

} 


iHandle, 
ulBuf fSize, 
*  pvBuff) 
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//  Check  file  state 

switch  (g_suI106Handle [iHandle] . enFileState) 

{ 

case  enclosed  : 

return  1 1 0  6_NOT  JOPEN  ; 
break; 

case  enWrite  : 

return  I106_WRONG_FILE_MODE; 
break; 

case  enReadData  : 
break; 

default  ; 

//  MIGHT  WANT  TO  SUPPORT  THE  "MORE  DATA"  METHOD  INSTEAD 

g_suI106Handle [iHandle] . enFileState  =  enReadUnsynced; 

return  110  6_READ_ERROR ; 

break; 

}  //  end  switch  file  state 

//  Make  sure  there  is  enough  room  in  the  user  buffer 
//  MIGHT  WANT  TO  SUPPORT  THE  "MORE  DATA"  METHOD  INSTEAD 

ulReadAmount  =  g_sul 10 6Handle [ iHandle] . ulCurrDataBuf fLen  - 

g_sul 10  6Handle [ iHandle]  . ulCurrDataBuf f ReadPos ; 
if  (ulBuffSize  <  ulReadAmount) 

return  I106_BUFFER_TOO_SMALL; 

//  Read  the  data,  filler,  and  data  checksum 

iReadCnt  =  read (g_suI106Handle [iHandle] . iFile,  pvBuff,  ulReadAmount); 

//  If  there  was  an  error  reading,  figure  out  why 
if  ((unsigned  long) iReadCnt  !=  ulReadAmount) 

{ 

g_suI106Handle [iHandle] . enFileState  =  enReadUnsynced; 
if  (iReadCnt  ==  -1) 

return  110  6_READ_ERROR ; 

else 

return  I106_EOF; 

}  //  end  if  read  error 

//  Keep  track  of  our  read  position  in  the  current  data  buffer 
g_suI106Handle [iHandle] . ulCurrDataBuf f ReadPos  =  ulReadAmount; 

//  MAY  WANT  TO  DO  CHECKSUM  CHECKING  SOMEDAY 

//  Expect  a  header  next  read 

g__suI106Handle [iHandle] . enFileState  =  enReadHeader; 

return  I106_OK; 

}  //  end  enI106Chl0ReadData ( ) 


/* 


*/ 


EnI106Status  I106_CALL_DECL 

enI106Chl0WriteMsg (int  iHandle, 

SuI106Chl0Header  *  psuHeader, 
void  *  pvBuff) 

{ 

int  iHeaderLen; 


A-2-12 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


int  iWriteCnt; 

//  Check  for  a  valid  handle 
if  ( (iHandle  <  0)  II 

(iHandle  >  MAX_HANDLES)  | | 

(g_suI106Handle [iHandle] .blnUse  ==  bFALSE) ) 

{ 

return  110  6_INVALI D_HANDLE ; 

} 

//  Figure  out  header  length 
iHeaderLen  =  iGetHeaderLen (psuHeader ) ; 

//  Write  the  header 

iWriteCnt  =  wr ite (g_sull 06Handle [ iHandle ]. iFile,  psuHeader,  iHeaderLen); 

//  If  there  was  an  error  reading,  figure  out  why 
if  (iWriteCnt  !=  iHeaderLen) 

{ 

return  I106_WRITE_ERROR; 

}  //  end  if  write  error 

//  Write  the  data 

iWriteCnt  =  write (g_suI106Handle [iHandle] . iFile,  pvBuff, 
psuHeader->ulPacketLen- iHeaderLen )  ; 

//  If  there  was  an  error  reading,  figure  out  why 

if  ((unsigned  long) iWriteCnt  !=  (psuHeader->ulPacketLen-iHeaderLen)  ) 

{ 

return  I106_WRITE_ERROR; 

}  //  end  if  write  error 

return  I106_OK; 

} 


/*  - 

*  Move  file  pointer 

*  - *  i 

EnI106Status  I106_CALL_DECL 

enI106Chl0FirstMsg (int  iHandle) 

{ 

if  (g_sull 06Handle [ iHandle ]. enFileMode  ==  I106_READ_IN_ORDER) 
g_suI106Handle [iHandle] . sulndex. iArrayCurr  =  0; 

enI106Chl0SetPos (iHandle,  0L)  ; 
return  I106_OK; 

} 


/* 


EnI106Status  I106_CALL_DECL 
enll 06Chl0LastMsg (int 
{ 


EnI106Status 

EnI106Status 

int64_t 

SuI106Chl0Header 


iHandle) 

enReturnStatus ; 
enStatus ; 

1 1 Po  s ; 
suHeader ; 


*/ 
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int  iReadCnt; 

struct  stat  suStatBuff; 

//  If  its  opened  for  reading  in  order  then  just  set  the  index  pointer 
//  to  the  last  index. 

if  (g_suI106Handle [iHandle] . enFileMode  ==  I106_READ_IN_ORDER) 

r 

g_suI106Handle [iHandle] . sulndex. iArrayCurr  = 

g_sull 06 Handle [iHandle ] .sulndex . iArrayUsed-1 ; 
enReturnStatus  =  I106_OK; 

} 

//  If  there  is  no  index  then  do  it  the  hard  way 
else 

{ 

//  enReturnStatus  =  I106_SEEK_ERROR; 

//  MAYBE  ALL  WE  NEED  TO  DO  TO  SEEK  TO  JUST  PAST  THE  END,  SET  UNSYNC ' ED  STATE, 

//  AND  THEN  CALL  enl 1 0 6Chl OPrevMsg ( ) 

//  Figure  out  how  big  the  file  is  and  go  to  the  end 
//  UPos  =  filelength (_fileno (g_sul 10 6Handle [iHandle ]. pFile) )  -  HEADER_SIZE; 

fstat (g_suI106Handle [iHandle] .iFile,  SsuStatBuff) ; 

UPos  =  suStatBuff . st_size  -  HEADER_SIZE; 

//if  (  (UPos  %  4)  !=  0) 

//  return  I106_SEEK_ERROR; 

//  Now  loop  forever  looking  for  a  valid  packet  or  die  trying 
while  (1==1) 

{ 

//  Not  at  the  beginning  so  go  back  1  byte  and  try  again 
UPos  -=  1; 

//  Go  to  the  new  position  and  look  for  a  legal  header 
enStatus  =  enI106Chl0SetPos (iHandle,  UPos) ; 
if  (enStatus  !=  I106_OK) 

return  I106_SEEK_ERROR; 

//  Read  and  check  the  header 

iReadCnt  =  read (g_suI106Handle [iHandle] . iFile,  SsuHeader,  HEADER_SIZE) 

if  (iReadCnt  !=  HEADERJ3IZE) 
continue ; 

if  (suHeader .uSync  !=  IRIG106J3YNC) 
continue ; 

//  Sync  pattern  matched  so  check  the  header  checksum 
if  ( suHeader . uChecksum  ==  uCalcHeaderChecksum (&suHeader ) ) 

{ 

enReturnStatus  =  I106_OK; 
break; 

} 

//  No  match,  check  for  begining  of  file 
if  (UPos  <=  0) 

{ 

enReturnStatus  =  I106_SEEK_ERROR; 
break; 

} 
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}  //  end  looping  forever 
}  //  end  if  not  read  in  order  mode 

//  Go  back  to  the  good  position 

enStatus  =  enI106Chl0SetPos (iHandle,  UPos) ; 

return  enReturnStatus ; 

} 


/*  -  */ 

EnI106Status  I106_CALL_DECL 

enI106Chl0SetPos (int  iHandle,  int64_t  llOffset) 

{ 

//  Check  for  a  valid  handle 
if  ( (iHandle  <  0)  II 

(iHandle  >  MAX_HANDLES)  | | 

(g_suI106Handle [iHandle] .blnUse  ==  bFALSE) ) 

{ 

return  I106_INVALID_HANDLE; 

} 

//  Seek 

#if  defined (_MSC_VER) 

{ 

_ int64  UStatus; 

UStatus  =  _lseeki64 (g_suI106Handle [iHandle] . iFile,  llOffset,  SEEK_SET) ; 

} 

#else 

lseek (g_suI106Handle [iHandle] . iFile,  llOffset,  SEEK_SET)  ; 

#endif 

//  Can't  be  sure  we're  on  a  message  boundary  so  set  unsync ' ed 
g_suI106Handle [iHandle] . enFileState  =  enReadUnsynced; 

return  I106_OK; 

} 


/* 


*/ 


EnI106Status  I106_CALL_DECL 

enI106Chl0GetPos (int  iHandle,  int64_t  *pllOffset) 

{ 

//  Check  for  a  valid  handle 
if  ( (iHandle  <  0)  II 

(iHandle  >  MAX_HANDLES)  | | 

(g_suI106Handle [iHandle] .blnUse  ==  bFALSE)) 

{ 

return  110  6_INVALI D_HANDLE ; 

} 

//  Get  position 
#if  defined (_MSC_VER) 

*pllOffset  =  _telli64 (g_suI106Handle [iHandle] . iFile) ; 

#else 

*pllOffset  =  lseek (g_suI106Handle [iHandle] . iFile,  0,  SEEK_CUR) ; 
#endif 
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return  I106_OK; 

} 


/*  - 

*  Utilities 

*  - *  i 

int  110  6_CALL_DECL 

iHeaderlnit (SuI106Chl0Header  *  psuHeader, 
unsigned  int  uChanID, 

unsigned  int  uDataType, 

unsigned  int  uFlags, 

unsigned  int  uSeqNum) 

{ 

//  Make  a  legal,  valid  header 
psuHeader->uSync  =  IRIG10 6_SYNC; 

psuHeader->uChID  =  uChanID; 

psuHeader->ulPacketLen  =  HEADER_SIZE; 

psuHeader->ulDataLen  =  0; 

psuHeader->ubyHdrVer  =  0x02; 

psuHeader->ubySeqNum  =  uSeqNum; 

psuHeader->ubyPacketFlags  =  uFlags; 

psuHeader->ubyDataType  =  uDataType; 

memset (& (psuHeader->aubyRefTime) ,  0,  6) ; 

psuHeader->uChecksum  =  uCalcHeaderChecksum (psuHeader ) ; 

memset (& (psuHeader->aulTime) ,  0,  8); 
psuHeader->uReserved  =  0; 

psuHeader->uSecChecksum  =  uCalcSecHeaderChecksum (psuHeader ) ; 

return  0; 

} 

/*  -  */ 

//  Figure  out  header  length  (might  need  to  check  header  version  at 
//  some  point  if  I  can  ever  figure  out  what  the  different  header 
//  version  mean. 

int  110  6_CALL_DECL 

iGetHeaderLen (SuI106Chl0Header  *  psuHeader) 

{ 

int  iHeaderLen; 

if  (  (psuHeader->ubyPacketFlags  &  I10  6CH10_PFLAGS_SEC_HEADER)  ==  0) 
iHeaderLen  =  HEADER_SIZE; 

else 

iHeaderLen  =  HEADER_SIZE  +  SEC_HEADER_S I ZE ; 

return  iHeaderLen; 

} 


/*  -  */ 

//  Figure  out  data  length  including  padding  and  any  data  checksum 
uint32  t  1106  CALL  DECL 
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uGetDataLen (SuI106Chl0Header  *  psuHeader) 

{ 

int  iDataLen; 

iDataLen  =  psuHeader->ulPacketLen  -  iGetHeaderLen (psuHeader ) ; 

return  iDataLen; 

} 


/*  -  */ 

uintl 6_t  110  6_CALL_DECL 

uCalcHeaderChecksum (SuI106Chl0Header  *  psuHeader) 

{ 

int  iHdrldx; 

uintl 6_t  uHdrSum; 

uintl6_t  *  aHdr  =  (uintl6_t  *)psuHeader; 

uHdrSum  =  0; 

for  ( iHdrIdx=0 ;  iHdr Idx< (HEADERJ3I ZE-2 ) /2 ;  iHdrIdx++) 
uHdrSum  +=  aHdr [ iHdr Idx] ; 

return  uHdrSum; 

} 


/*  -  */ 

uintl 6_t  110  6_CALL_DECL 

uCalcSecHeaderChecksum (SuI106Chl0Header  *  psuHeader) 

{ 

int  iByteldx; 

uintl 6_t  uHdrSum; 

//  MAKE  THis  16  BIT  UNSIGNEDS  LIKE  ABOVE 

unsigned  char  *  auchHdrByte  =  (unsigned  char  *) psuHeader ; 

uHdrSum  =  0; 

for  ( iByteIdx=0 ;  iByteIdx<SEC_HEADER_SIZE-2 ;  iByteIdx++) 
uHdrSum  +=  auchHdrByte [iByteIdx+HEADER_SIZE] ; 

return  uHdrSum; 

} 


/*  -  */ 

//  Calculate  and  return  the  required  size  of  the  data  buffer  portion  of  the 
//  packet  including  checksum  and  appropriate  filler  for  4  byte  alignment. 

uint32_t  110  6_CALL_DECL 

uCalcDataBuf fReqSize  (uint32_t  uDataLen,  int  iChecksumType ) 

{ 

uint32_t  uDataBuf fLen; 

//  Start  with  the  length  of  the  data 
uDataBuffLen  =  uDataLen; 

//  Add  in  enough  for  the  selected  checksum 
switch  (iChecksumType) 

{ 
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case  1 1 0 6CH1 0_PFLAGS_CHKSUM_NONE  : 
break; 

case  1 1 0 6CH1 0_PFLAGS_CHKSUM_8  : 

uDataBuffLen  +=  1; 
break; 

case  1 1 0 6CH1 0_PFLAGS_CHKSUM_1 6  : 

uDataBuffLen  +=  2; 
break; 

case  110  6CH1 0_PFLAGS_CHKSUM_32  : 

uDataBuffLen  +=  4; 
break; 
default  : 

uDataBuffLen  =  0; 

}  //  end  switch  iChecksumType 

//  Now  add  filler  for  4  byte  alignment 
uDataBuffLen  +=  3; 
uDataBuffLen  &=  Oxfffffffc; 

return  uDataBuffLen; 

} 


/*  -  */ 

//  Add  the  filler  and  appropriate  checksum  to  the  end  of  the  data  buffer 
//  It  is  assumed  that  the  buffer  is  big  enough  to  hold  additional  filler 
//  and  the  checksum.  Also  fill  in  the  header  with  the  correct  packet  length. 

EnI106Status  I106_CALL_DECL 

uAddDataFillerChecksum (SuI106Chl0Header  *  psuI106Hdr,  unsigned  char  achDataf]) 

{ 

uint32_t  uDataldx; 

uint32_t  uDataBuf fSize; 

uint32_t  uFillSize; 

int  iChecksumType; 

uint8_t  *puSum8; 

uint8_t  *puData8; 

uintl6_t  *puSuml6; 
uintl6_t  *puDatal6; 
uint32_t  *puSum32; 
uint32_t  *puData32; 

//  Extract  the  checksum  type 

iChecksumType  =  psuI106Hdr->ubyPacketFlags  &  0x03; 

//  Figure  out  how  big  the  final  packet  will  be 

uDataBuf fSize  =  uCalcDataBuf fReqSize (psuI106Hdr->ulDataLen,  iChecksumType); 
psuI106Hdr->ulPacketLen  =  HEADER_SIZE  +  uDataBuffSize; 
if  ( (psuI106Hdr->ubyPacketFlags  &  I106CH10_PFLAGS_SEC_HEADER)  !=  0) 
psul 10  6Hdr->ulPacketLen  +=  SEC_HEADERJ3IZE; 

//  Figure  out  the  filler/checksum  size  and  zero  fill  it 
uFillSize  =  uDataBuffSize  -  psuI106Hdr->ulDataLen; 
memset (SachData [psuI106Hdr->ulDataLen]  ,  0,  uFillSize); 

//  If  no  checksum  then  we're  done 

if  (iChecksumType  ==  I106CH10_PFLAGS_CHKSUM_NONE) 
return  I106_OK; 

//  Calculate  the  checksum 
switch  (iChecksumType) 
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case  1 1 0 6CH1 0_PFLAGS_CHKSUM_8  : 

//  Checksum  the  data  and  filler 
puData8  =  (uint8_t  *)achData; 

puSum8  =  (uint8_t  * ) SachData [psull 06Hdr->ulDataLen+uFillSize-l ] ; 
for  (uDataIdx=0;  uDataldxkuDataBuff Size-1 ;  uDataIdx++) 

{ 

*puSum8  +=  *puData8; 
puData8++; 

} 

break; 

case  1 1 0 6CH1 0_PFLAGS_CHKSUM_1 6  : 

puDatal6  =  (uintl6_t  *)achData; 

puSuml6  =  (uintl6_t  *) SachData [psull 06Hdr->ulDataLen+uFillSize-2 ] ; 

for  (uDataIdx=0;  uDataldxk (uDataBuff Size/2 ) -1 ;  uDataIdx++) 

{ 

*puSuml6  +=  *puDatal6; 
puDatal6++; 

} 

break; 

case  110  6CH1 0_PFLAGS_CHKSUM_32  : 
puData32  =  (uint32_t  *)achData; 

puSum32  =  (uint32_t  *) SachData [psull 06Hdr->ulDataLen+uFillSize-4 ] ; 

for  (uDataIdx=0;  uDataldxk (uDataBuff Size/ 4 ) -1 ;  uDataIdx++) 

{ 

*puSum32  +=  *puData32; 
puData32++; 

} 

break; 
default  : 
break; 

}  //  end  switch  iChecksumType 

return  I106_OK; 

} 


//  - 

//  Generate  an  index  from  the  data  file 
//  - 

/* 

Support  for  read  back  in  time  order  is  experimental.  Some  106-04  recorders 
recorder  data  *way*  out  of  time  order.  But  most  others  don't.  And  starting 
with  106-05  the  most  out  of  order  is  1  second. 

The  best  way  to  support  read  back  in  order  is  to  do  it  on  the  fly  as  the  file 
is  being  read.  But  that's  more  than  I'm  willing  to  do  right  now.  This  indexing 
scheme  does  get  the  job  done  for  now. 

*/ 

//  Read  the  index  from  a  previously  generated  index  file, 
int  110  6_CALL_DECL 

bReadlnOrder Index ( int  iHandle,  char  *  szIdxFileName) 

{ 


int 

ildxFile ; 

int 

iFlags ; 

int 

iArrayReadStart 

int 

iReadCnt ; 

A-2-19 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


int  bReadOK  =  bFALSE; 

Sulndex  *  psulndex  =  &g_suI106Handle [iHandle] . sulndex; 

//  Setup  a  one  time  loop  to  make  it  easy  to  break  out  on  errors 
do 

{ 

//  Try  opening  and  reading  the  index  file 
#if  defined (_MSC_VER) 

iFlags  =  0_RD0NLY  |  0_BINARY; 

#else 

iFlags  =  0_RD0NLY; 

#endif 

ildxFile  =  open ( szIdxFileName,  iFlags,  0)  ; 
if  (ildxFile  ==  -1) 
break; 

//  Read  the  index  data  from  the  file 
while  (bTRUE) 

{ 

iArrayReadStart  =  psuIndex->iArraySize; 
psuIndex->iArraySize  +=  100; 

psulndex->asulndex  =  (SuFilelndex  *) realloc (psulndex->asulndex, 
sizeof  (SuFilelndex) *psuIndex->iArraySize) ; 
iReadCnt  =  read (ildxFile,  & (psulndex->asulndex [ iArrayReadStart] ) , 
100*sizeof (SuFilelndex) ) ; 

psuIndex->iArrayUsed  +=  iReadCnt  /  sizeof (SuFilelndex) ; 
if  (iReadCnt  !=  100*sizeof (SuFilelndex) ) 
break; 

}  //  end  while  reading  data  from  file 
close (ildxFile) ; 

//  MIGHT  WANT  TO  DO  SOME  SANITY  CHECKS  IN  HERE 

psuIndex->enSortStatus  =  enSorted; 
bReadOK  =  bTRUE; 

}  while  (bFALSE);  //  end  one  time  loop  to  read 

return  bReadOK; 

} 


//  - 

int  I106_CALL_DECL 

bWritelnOrderlndex ( int  iHandle,  char  *  szIdxFileName) 

{ 

int  iFlags; 

int  ildxFile; 

int  iWriteldx; 

Sulndex  *  psulndex  =  &g_suI106Handle [iHandle] . sulndex; 

//  Write  out  an  index  file  for  use  next  time 
#if  defined (_MSCJVER) 

iFlags  =  0_WR0NLY  |  0_CREAT  |  0_BINARY; 

#else 

iFlags  =  0_WR0NLY  |  0_CREAT; 

#endif 

ildxFile  =  open ( szIdxFileName,  iFlags,  _S_IREAD  |  _S_IWRITE) ; 
if  (ildxFile  !=  -1) 

{ 


A-2-20 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


//  Read  the  index  data  from  the  file 

for  ( iWriteIdx=0 ;  iWriteIdx<psuIndex->iArrayUsed;  iWriteIdx++) 

{ 

write (ildxFile,  & (psulndex->asulndex [iWriteldx] ) ,  sizeof (SuFilelndex) ) ; 
}  //  end  for  all  index  array  elements 

close ( ildxFile ) ; 

} 


return  b FALSE; 

} 


//  - 

//  This  is  used  in  qsort  in  vMakelnOrder Index ( )  below 

int  FileTimeCompare (const  void  *  psulndexl,  const  void  *  psulndex2) 

{ 

if  (((SuFilelndex  *) psulndexl ) ->llTime  <  ((SuFilelndex  *) psulndex2) ->llTime)  return  -1 
if  (((SuFilelndex  *) psulndexl ) ->llTime  >  ((SuFilelndex  *) psulndex2) ->llTime)  return  1 
return  0; 

} 


//  - 

//  Read  all  headers  and  make  an  index  based  on  time 


void  I106_CALL_DECL 

vMakelnOrder Index ( int  iHandle) 

{ 


EnI106Status 

int64_t 

int64_t 

SuI106Chl0Header 

int64_t 

Sulndex 


~k 


enStatus ; 
UStartPos  ; 
HCurrPos  ; 
suHdr ; 
HCurrTime  ; 
psulndex  = 


//  File  position  coming  in 
//  Current  file  position 
//  Data  packet  header 
//  Current  header  time 
&g_sull 06 Handle [ iHandle] . sulndex; 


//  Remember  the  current  file  position 

enStatus  =  enI106Chl0GetPos (iHandle,  SllStartPos)  ; 


enStatus  =  enI106Chl0SetPos (iHandle,  0L) ; 

//  Read  headers,  put  time  and  file  offset  into  index  array 
while  (bTRUE) 

{ 

enStatus  =  enI106Chl0ReadNextHeaderFile (iHandle,  &suHdr) ; 


//  If  EOF  break  out 
if  (enStatus  ==  I106_EOF) 
break; 

//  If  an  error  then  clean  up  and  get  out 
if  (enStatus  !=  I106_OK) 

{ 

free (psulndex->asulndex) ; 
psulndex->asulndex  =  NULL; 

psuIndex->iArraySize  =  0; 

psu!ndex->iArrayUsed  =  0; 
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psuIndex->iNumSearchSteps  =  0; 
psuIndex->enSortStatus  =  enSortError; 
break; 

} 


//  Get  the  time  and  position 

enStatus  =  enI106Chl0GetPos  (iHandle,  StllCurrPos)  ; 

HCurrPos  -=  iGetHeaderLen (SsuHdr) ; 
vTimeArray2LLInt  ( suHdr  .  aubyRef Time ,  &HCurrTime)  ; 

//  Check  the  array  size,  make  it  bigger  if  necessary 
if  (psuIndex->iArrayUsed  >=  psuIndex->iArraySize) 

{ 

psuIndex->iArraySize  +=  100; 
psulndex->asulndex  = 

(SuFilelndex  *) realloc (psulndex->asulndex, 
sizeof  (SuFilelndex) *psuIndex->iArraySize) ; 

} 

//  Copy  the  info  into  the  next  array  element 

psulndex->asulndex [psuIndex->iArrayUsed] . llOf fset  =  HCurrPos; 
psulndex->asulndex [psuIndex->iArrayUsed] . UTime  =  HCurrTime; 
psuIndex->iArrayUsed++ ; 

} 


//  Sort  the  index  array 

//  It  is  required  that  TMATS  is  the  first  record  and  IRIG  time  is  the 
//  second  record  so  don't  include  those  in  the  sort 
qsort ( & (psulndex->asulndex [2 ] ) ,  psuIndex->iArrayUsed-2 , 
sizeof (SuFilelndex)  ,  FileTimeCompare) ; 

//  Put  the  file  point  back  where  we  started  and  find  the  current  index 
//  THIS  SHOULD  REALLY  BE  DONE  FOR  THE  FILE-READ-OK  LOGIC  PATH  ALSO 
enStatus  =  enI106Chl0SetPos (iHandle,  UStartPos); 
psuIndex->iArrayCurr  =  0; 

while  (psuIndex->iArrayCurr  <  psuIndex->iArrayUsed) 

{ 

if  (UStartPos  ==  psulndex->asulndex [psuIndex->iArrayCurr ] . llOf fset) 
break; 

psuIndex->iArrayCurr++ ; 

} 

//  If  we  didn't  find  it  then  it's  an  error 
if  (psuIndex->iArrayCurr  ==  psuIndex->iArrayUsed) 

{ 

free  (psulndex->asulndex) ; 
psulndex->asulndex  =  NULL; 

psuIndex->iArraySize  =  0; 

psuIndex->iArrayUsed  =  0; 

psuIndex->iNumSearchSteps  =  0; 

psuIndex->enSortStatus  =  enSortError; 

} 

else 

psuIndex->enSortStatus  =  enSorted; 

return ; 

} 
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APPENDIX  A-3  -  1106  TIME.H 

/**************************************************************************** 
il06_time.h  - 

Copyright  (c)  2006  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#ifndef  _I106_TIME_H 
#def ine  _I106_TIME_H 

//  #include  "irigl06chl0 .h" 

#ifdef  _ cplusplus 

extern  "C"  { 

#endif 

/* 

*  Macros  and  definitions 

*  _ 

*/ 


typedef  enum 

{ 

110  6_DATEFMT_DAY  =  0, 

I106_DATEFMT_DMY  =  1, 

}  EnI106DateFmt; 

/* 

*  Data  structures 
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'/ 


//  Time  has  a  number  of  representations  in  the  IRIG  106  spec. 

//  The  structure  below  is  used  as  a  convenient  standard  way  of 
//  representing  time.  The  nice  thing  about  standards  is  that  there 
//  are  so  many  to  choose  from,  and  time  is  no  exception.  But  none  of 
//  the  various  C  time  representations  really  fill  the  bill.  So  I  made 
//  a  new  time  representation.  So  there, 
typedef  struct 
{ 


uint32_t  ulSecs; 
uint32_t  ulFrac; 
EnI106DateFmt  enFmt; 

}  SuIrigl06Time; 


//  This  is  a  time_t 
//  LSB  =  100ns 
//  Day  or  DMY  format 


//  Relative  time  to  absolute  time  reference 
typedef  struct 
{ 

uint64_t  uRelTime;  //  Relative  time  from  header 

SuIrigl06Time  suIrigTime;  //  Clock  time  from  IRIG  source 

}  SuTimeRef; 


III  IRIG  106  secondary  header  time  in  Ch  4  BCD  format 
typedef  PUBLIC  struct  SuI106Ch4_BCD_Time_S 
{ 


uintl6  t 

uMinl 

4 

;  //  High  order  time 

uintl6  t 

uMinlO 

3 

uintl6  t 

uHourl 

4 

uintl6  t 

uHourl 0 

2 

uintl6  t 

uDayl 

3 

uintl6  t 

uSecO  01 

4 

;  //  Low  order  time 

uintl6  t 

uSecO  1 

4 

uintl6  t 

uSecl 

4 

uintl6  t 

uSeclO 

2 

uintl6  t 

uReserved 

2 

uintl6  t 

uUSecs ; 

//  Microsecond  time 

#if  !defined( 

GNUC _ ) 

}  SuI106Ch4 

BCD  Time; 

#else 

}  attribute  ( (packed) 

)  SuI106Ch4  BCD  Time; 

#endif 

III  IRIG  106  secondary  header  time  in  Ch  4  binary  format 
typedef  PUBLIC  struct  SuI106Ch4_Binary_Time_S 
{ 

uintl6_t  uHighBinTime ; 

uintl6_t  uLowBinTime; 

uintl6_t  uUSecs; 

#if  ! defined ( _ GNUC _ ) 

}  SuI106Ch4_Binary_Time; 

#else 

}  _ attribute _  ( (packed) )  SuI106Ch4_Binary_Time; 

#endif 


//  High  order  time 
/ /  Low  order  time 
//  Microsecond  time 


III  IRIG  106  secondary  header  time  in  IEEE-1588  format 
typedef  PUBLIC  struct  SuIEEE1588_Time_S 
{ 

uint32_t  uNanoSeconds ;  //  Nano-seconds 

uint32  t  uSeconds;  //  Seconds 
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#if  ! defined ( _ GNUC _ ) 

}  SuIEEE1588_Time; 

#else 

}  _ attribute _  ( (packed) )  SuIEEE1588_Time; 

#endif 


III  Intra-packet  header  relative  time  counter  format 
typedef  PUBLIC  struct  SuIntraPacketRtc_S 
{ 

uint8_t  aubyRefTime [ 6 ] ;  //  Reference  time 

uintl6_t  uReserved; 

#if  ! defined ( _ GNUC _ ) 

}  SuIntraPacketRtc; 

#else 

}  _ attribute _  ( (packed) )  SuIntraPacketRtc; 

#endif 


/* 

*  Global  data 

~k _ 

*/ 


I* 

*  Function  Declaration 

~k _ 

*1 

EnI106Status  I106_CALL_DECL 
enll 06_SetRelTime ( int 

SuIrigl06Time 
uint8_t 

EnI106Status  I106_CALL_DECL 
enI106_Rel2IrigTime (int 

uint8_t 
SuIrigl06Tii 

EnI106Status  I106_CALL_DECL 

enI106_Irig2RelTime (int  iI106Chl0Handle, 

SuIrigl06Time  *  psuTime, 
uint8_t  abyRelTime [ ] ) ; 

//  Warning  -  array  to  int  /  int  to  array  functions  are  little  endian  only! 

void  110  6_CALL_DECL 

vLLInt2TimeArray (int64_t  *  pllRelTime, 

uint8_t  abyRelTime [ ] ) ; 


void  I106_CALL_DECL 

vTimeArray2LLInt (uint8_t  abyRelTime [ ] , 
int64_t  *  pllRelTime) ; 


EnI106Status  I106_CALL_DECL 

enI106_SyncTime (int  iI106Chl0Handle, 

int  bRequireSync,  //  Require  external  time  sync 

int  iTimeLimit) ;  //  Max  scan  ahead  time  in  seconds,  0  =  no  limit 

EnI106Status  1106  CALL  DECL 
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iI106Chl0Handle, 
*  psuTime, 

abyRelTime [ ] ) ; 


iI106Chl0Handle, 
abyRelTime [ ] , 

*  psuTime) ; 
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enI106Chl0SetPosToIrigTime (int  iI106Chl0Handle,  SuIrigl06Time  *  psuSeekTime ) 


//  General  purpose  time  utilities 
// - 

//  Convert  IRIG  time  into  an  appropriate  string 
char  *  IrigTime2String (SuIrigl06Time  *  psuTime) ; 

//  IT  WOULD  BE  NICE  TO  HAVE  SOME  FUNCTIONS  TO  COMPARE  6  BYTE 
//  TIME  ARRAY  VALUES  FOR  EQUALITY  AND  INEQUALITY 

//  This  is  handy  enough  that  we'll  go  ahead  and  export  it  to  the  world 
//  HMMM. . .  MAYBE  A  BETTER  WAY  TO  DO  THIS  IS  TO  MAKE  THE  TIME  VARIABLES 
//  AND  STRUCTURES  THOSE  DEFINED  IN  THIS  PACKAGE. 
time_t  110  6_CALL_DECL 

mkgmtime ( struct  tm  *  psuTmTime) ; 

#ifdef  _ cplusplus 

} 

fendif 

#endif 
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APPENDIX  A-4  -  I106TIME.C 


il06_time.c  - 

Copyright  (c)  2006  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 


*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 


#include 

#include 

#include 

#include 


<stdio . h> 
<stdlib . h> 
<string . h> 
<time . h> 


#include 

#include 

#include 

#include 


" stdint . h" 

" iriglO  6chl 0 . h" 

" il 06_time . h" 

"il06  decode  time.h" 


/* 

*  Macros  and  definitions 


*/ 


/* 

*  Data  structures 


*/ 


/* 

*  Module  data 
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_ 

*/ 

static  SuTimeRef  m_asuTimeRef [MAX_HANDLES ] ;  //  Relative  /  absolute  time  reference 
/* 

*  Function  Declaration 


*/ 


/*  -  */ 

//  Update  the  current  reference  time  value 
EnI106Status  I106_CALL_DECL 

enll 06_SetRelTime (int  ill 06Chl OHandle, 

SuIrigl06Time  *  psuTime, 
uint8_t  abyRelTime [ ] ) 

{ 

//  Save  the  absolute  time  value 

m_asuTimeRef [iI106Chl0Handle] . sulr igTime . ulSecs  =  psuTime->ulSecs ; 
m_asuTimeRef [iI106Chl0Handle] . sulr igTime . ulFrac  =  psuTime->ulFrac ; 
m_asuTimeRef [iI106Chl0Handle] . sulr igTime . enFmt  =  psuTime->enFmt; 

//  Save  the  relative  (i.e.  the  10MHz  counter)  value 
m_asuTimeRef [iI106Chl0Handle] . uRelTime  =  0; 

memcpy ( ( char  * ) & (m_a suTimeRef [ il 10 6Chl OHandle ]  . uRelTime) , 

(char  *) SabyRelTime [0] ,  6); 

return  I106_OK; 

} 


/*  -  */ 

//  Take  a  6  byte  relative  time  value  (like  the  one  in  the  IRIG  header)  and 
//  turn  it  into  a  real  time  based  on  the  current  reference  IRIG  time. 


EnI106Status  I106_CALL_DECL 
enI106_Rel2IrigTime (int 

uint8  t 


SuIrigl06Time 


{ 

uint64_t 
int64_t 
int64_t 
int64_t 

int64_t 
int64_t 

uRelTime  =  0L; 
memcpy (SuRelTime 


uRelTime ; 
uTimeDif f ; 
lFracDif f ; 
lSecDiff ; 

lSec; 

lFrac; 


SabyRelTime [0] 


ill 06Chl OHandle 
abyRelTime [ ]  , 

*  psuTime) 


//  Figure  out  the  relative  time  difference 

uTimeDiff  =  uRelTime  -  m_asuTimeRef [iI106Chl0Handle] . uRelTime; 
lSecDif f  =  uTimeDiff  /  lOOOOOOO; 
lFracDiff  =  uTimeDiff  %  10000000; 


lSec  =  m_asuTimeRef [ ill 06Chl0Handle ]. suIrigTime . ulSecs  +  lSecDiff; 

lFrac  =  m_asuTimeRef [ ill 06Chl0Handle ]. suIrigTime . ulFrac  +  lFracDiff; 
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//  This  seems  a  bit  extreme  but  it's  defensive  programming 
while  (lFrac  <  0) 

{ 

lFrac  +=  10000000; 
lSec  -=  1; 

} 


while  (lFrac 

{ 

lFrac  -= 
lSec  += 
} 


>=  10000000) 

10000000; 

1; 


//  Now  add  the  time  difference  to  the  last  IRIG  time  reference 
psuTime->ulFrac  =  (unsigned  long) lFrac; 
psuTime->ulSecs  =  (unsigned  long) lSec; 

return  I106_OK; 

} 


/*  -  */ 

//  Take  a  real  clock  time  and  turn  it  into  a  6  byte  relative  time. 

EnI106Status  I106_CALL_DECL 
enI106_Irig2RelTime (int 

SuIrigl06Time 
uint8_t 

{ 

int64_t  UDiff; 

int64_t  UNewRel; 

//  Calculate  time  difference  (LSB  =  100  nSec)  between  the  passed  time 
//  and  the  time  reference 
UDiff  = 

(int64_t) (t  psuTime->ulSecs  -  m_asuTimeRef [ ill 06Chl0Handle ] . suIrigTime . ulSecs) 
10000000  + 

(int64_t) (+  psuTime->ulFrac  -  m_asuTimeRef [ ill 06Chl0Handle ]. suIrigTime . ulFrac) 
//  Add  this  amount  to  the  reference 

UNewRel  =  m_asuTimeRef  [  il  10  6Chl  OHandle]  .  uRelTime  +  UDiff; 

//  Now  convert  this  to  a  6  byte  relative  time 
memcpy((char  * ) SabyRelTime [ 0 ]  , 

(char  *)&  (UNewRel)  ,  6); 

return  I106_OK; 

} 


ill 06Chl OHandle, 
*  psuTime, 

abyRelTime [ ] ) 


/*  -  */ 

//  Warning  -  array  to  int  /  int  to  array  functions  are  little  endian  only! 

//  Create  a  6  byte  array  value  from  a  64  bit  int  relative  time 
void  1106  CALL  DECL 
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vLLInt2TimeArray (int64_t  *  pllRelTime, 

uint8_t  abyRelTime [ ] ) 

{ 

memcpy((char  *) abyRelTime,  (char  *) pllRelTime,  6); 
return ; 

} 


/*  -  */ 

//  Create  a  64  bit  int  relative  time  from  6  byte  array  value 
void  I106_CALL_DECL 

vTimeArray2LLInt (uint8_t  abyRelTime [ ] , 
int64_t  *  pllRelTime) 

{ 

*pllRelTime  =  0L; 

memcpy((char  *) pllRelTime,  (char  *) abyRelTime,  6); 
return ; 

} 


/* 


*/ 


//  Read  the  data  file  from  the  current  position  to  try  to  determine  a  valid 
//  relative  time  to  clock  time  from  a  time  packet. 


EnI106Status  1106  CALL  DECL 


enll 06_SyncTime (int 
int 
int 


{ 

int64_t 

int64_t 

int64_t 

EnI106Status 

EnI106Status 

SuI106Chl0Header 

SuIrigl06Time 

unsigned  long 

void  * 

SuTimeFl_ChanSpec  * 


iI106Chl OHandle, 

bRequireSync, 

iTimeLimit) 

HCurrOf  fset; 

1 ITimeLimit ; 
HCurrTime  ; 
enStatus ; 
enRetStatus; 
suI106Hdr; 
suTime ; 

ulBuffSize  =  0; 
pvBuff  =  NULL; 
psuChanSpecTime; 


psuChanSpecTime  =  (SuTimeFl_ChanSpec  *)pvBuff; 


//  Get  and  save  the  current  file  position 

enStatus  =  enI106Chl0GetPos (iI106Chl0Handle,  SllCurrOf f set) ; 
if  (enStatus  !=  I106_OK) 
return  enStatus; 


//  Read  the  first  header 

enStatus  =  enI106Chl0ReadNextHeaderFile (iI106Chl0Handle,  &suI106Hdr)  ; 
if  (enStatus  ==  I106_EOF) 

return  I106_TIME_NOT_FOUND; 

if  (enStatus  !=  I106_OK) 
return  enStatus; 

//  Calculate  the  time  limit  if  there  is  one 
if  (iTimeLimit  >  0) 

{ 

vTimeArray2LLInt  ( sul  10  6Hdr  .  aubyRef  Time,  &HTimeLimit)  ; 
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UTimeLimit  =  UTimeLimit  +  (int64_t)  iTimeLimit  *  ( int64_t)  10000000 ; 

} 

else 

UTimeLimit  =  0; 

//  Loop,  looking  for  appropriate  time  message 
while  (bTRUE) 

{ 

//  See  if  we've  passed  our  time  limit 
if  (UTimeLimit  >  0) 

{ 

vTimeArray2LLInt ( sul 10  6Hdr . aubyRefTime,  StllCurrTime) ; 
if  (UTimeLimit  <  HCurrTime) 

{ 

enRetStatus  =  I106_TIME_NOT_FOUND; 
break; 

} 

}  //  end  if  there  is  a  time  limit 
//  If  IRIG  time  type  then  process  it 

if  ( sull 06Hdr . ubyDataType  ==  I106CH10_DTYPE_IRIG_TIME) 

{ 

//  Read  header  OK,  make  buffer  for  time  message 
if  (ulBuffSize  <  sul 10 6Hdr . ulPacketLen) 

{ 

pvBuff  =  realloc (pvBuff,  sul 106Hdr . ulPacketLen) ; 
ulBuffSize  =  sul 10 6Hdr . ulPacketLen; 

} 

//  Read  the  data  buffer 

enStatus  =  enI106Chl0ReadData (iI106Chl0Handle,  ulBuffSize,  pvBuff); 
if  (enStatus  !=  I106_OK) 

{ 

enRetStatus  =  I106_TIME_NOT_FOUND; 
break; 

} 

//  If  external  sync  OK  then  decode  it  and  set  relative  time 

if  ( (bRequireSync  ==  bFALSE)  | |  (psuChanSpecTime->uTimeSrc  ==  1)) 

{ 

enI106_Decode_TimeFl (&suI106Hdr,  pvBuff,  SsuTime) ; 

enll 06_SetRelTime ( il 10  6Chl OHandle,  &suTime,  sul 10  6Hdr . aubyRefTime) ; 

enRetStatus  =  I106_OK; 

break; 

} 

}  //  end  if  IRIG  time  message 
//  read  the  next  header  and  try  again 

enStatus  =  enI106Chl0ReadNextHeaderFile (iI106Chl0Handle,  &suI106Hdr) ; 
if  (enStatus  ==  I106_EOF) 

{ 

enRetStatus  =  I106_TIME_NOT_FOUND; 
break; 

} 

if  (enStatus  !=  I106_OK) 

{ 

enRetStatus  =  enStatus; 
break; 

} 
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}  //  end  while  looping  looking  for  time  message 
//  Restore  file  position 

enStatus  =  enI106Chl0SetPos (iI106Chl0Handle,  HCurrOf f set) ; 
if  (enStatus  !=  I106_OK) 

{ 

enRetStatus  =  enStatus; 

} 


//  Return  the  malloc'ed  memory 
free  (pvBuff) ; 

return  enRetStatus; 

} 


/* 


*/ 


EnI106Status  I106_CALL_DECL 

enI106Chl0SetPosToIrigTime (int  iHandle,  SuIrigl06Time  *  psuSeekTime) 

{ 

uint8_t  abySeekTime [ 6] ; 

int64_t  USeekTime; 

Sulndex  *  psulndex  =  &g_sull 06Handle [ iHandle] . sulndex; 

int  iUpperLimit; 

int  iLowerLimit; 

int  iSearchLoopIdx; 


//  If  there  is  no  index  in  memory  then  barf 
if  (psuIndex->enSortStatus  !=  enSorted) 
return  I106_NO_INDEX; 

//We  have  an  index  so  do  a  binary  search  for  time 


//  Convert  clock  time  to  10  MHz  count 

enI106_Irig2RelTime (iHandle,  psuSeekTime,  abySeekTime); 
vTimeArray2LLInt (abySeekTime ,  SllSeekTime) ; 


//  Check  time  bounds 

if  (USeekTime  <  psulndex->asulndex  [ 0 ]  .  UTime) 

{ 

enI106Chl0FirstMsg (iHandle)  ; 
return  I106_TIME_NOT_FOUND; 

}  ; 


if  (USeekTime  >  psulndex->asulndex  [psuIndex->iArrayUsed]  .  UTime) 

{ 

enll 06Chl0LastMsg ( iHandle) ; 
return  I106_TIME_NOT_FOUND; 

}  ; 


//  If  we  don't  already  have  it,  figure  out  how  many  search  steps 
if  (psuIndex->iNumSearchSteps  ==  0) 

{ 

iUpperLimit  =  1; 

while  (iUpperLimit  <  psuIndex->iArrayUsed) 

{ 

iUpperLimit  *=  2; 
psuIndex->iNumSearchSteps+t ; 

} 

}  //  end  if  no  search  steps 
//  Loop  prescribed  number  of  times 
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iLowerLimit  =  0; 

iUpperLimit  =  psuIndex->iArrayUsed-l ; 

psuIndex->iArrayCurr  =  (iUpperLimit  -  iLowerLimit)  /  2; 
for  ( iSearchLoopIdx  =  0; 

iSearchLoopIdx  <  psuIndex->iNumSearchSteps; 
iSearchLoopIdx++) 

{ 

if  (psulndex->asulndex [psuIndex->iArrayCurr ] . UTime  >  USeekTime) 

iUpperLimit  =  (iUpperLimit  -  iLowerLimit)  /  2; 
else  if  (psulndex->asulndex [psuIndex->iArrayCurr ] . UTime  <  USeekTime) 
iLowerLimit  =  (iUpperLimit  -  iLowerLimit)  /  2; 

else 

break; 

} 


return  I106_OK; 

} 


/*  -  */ 

//  General  purpose  time  utilities 
// - 

//  Convert  IRIG  time  into  an  appropriate  string 

char  *  IrigTime2String (SuIrigl06Time  *  psuTime) 

{ 

static  char  szTime [30]; 

struct  tm  *  psuTmTime; 

//  Convert  IRIG  time  into  it's  components 
psuTmTime  =  gmtime ( ( time_t  * ) & (psuTime->ulSecs)  )  ; 

//  Make  the  appropriate  string 
switch  (psuTime->enFmt) 

{ 

//  Day  /  Month  /  Year  format  ("001:12:34:56.789") 
case  110  6_DATEFMT_DMY  : 

sprintf ( szTime,  "%4 . 4i/%2 . 2i/%2 . 2i  %2 . 2i : %2 . 2i : %2 . 2i . %3 . 3i" , 
psuTmTime->tm_year  +  1900, 
psuTmTime->tm_mon  +  1, 
psuTmTime->tm_mday , 
psuTmTime->tm_hour , 
psuTmTime->tm_min, 
psuTmTime->tm_sec, 
psuTime->ulFrac  /  10000) ; 
break; 

//  Day  of  the  Year  format  ("2008/02/29  12:34:56.789") 
case  110  6_DATEFMT_DAY  : 
default  : 

sprintf ( szTime,  "%3.3i:%2.2i:%2.2i:%2.2i.%3.3i", 
psuTmTime->tm_ydaytl , 
psuTmTime->tm_hour , 
psuTmTime->tm_min, 
psuTmTime->tm_sec, 
psuTime->ulFrac  /  10000) ; 
break; 

}  //  end  switch  on  format 

return  szTime; 

} 
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/*  -  */ 

/*  Return  the  equivalent  in  seconds  past  12:00:00  a.m.  Jan  1,  1970  GMT 

of  the  Greenwich  Mean  time  and  date  in  the  exploded  time  structure  'tm'. 

The  standard  mktimeO  has  the  annoying  "feature"  of  assuming  that  the 
time  in  the  tm  structure  is  local  time,  and  that  it  has  to  be  corrected 
for  local  time  zone.  In  this  library  time  is  assumed  to  be  UTC  and  UTC 
only.  To  make  sure  no  timezone  correction  is  applied  this  time  conversion 
routine  was  lifted  from  the  standard  C  run  time  library  source.  Interestingly 
enough,  this  routine  was  found  in  the  source  for  mktimeO . 

This  function  does  always  put  back  normalized  values  into  the  'tm'  struct, 
parameter,  including  the  calculated  numbers  for  ' tm->tm_yday ' , 

' tm->tm_wday ' ,  and  ' tm->tm_isdst ' . 

Returns  -1  if  the  time  in  the  'tm'  parameter  cannot  be  represented 
as  valid  'time  t'  number. 


//  Number  of  leap  years  from  1970  to  'y'  (not  including  'y'  itself) . 

#def ine  nleap(y)  ( ( (y)  -  1969)  /  4  -  ( (y)  -  1901)  /  100  +  ( (y)  -  1601)  /  400) 

//  Nonzero  if  'y'  is  a  leap  year,  else  zero. 

#define  leap(y)  ( ( (y)  %  4  ==  0  &&  (y)  %  100  !  =  0)  ||  (y)  %  400  ==  0) 

//  Additional  leapday  in  February  of  leap  years. 

#define  leapday (m,  y)  ( (m)  ==  1  &&  leap  (y)  ) 

#define  ADJUST_TM (tm_member,  tm_carry,  modulus)  \ 
if  ( (tm_member)  <  0)  {  \ 

tm_carry  -=  (1  -  ( ( tm_member ) +1 )  /  (modulus));  \ 
tm_member  =  (modulus-1)  +  ( ( ( tm_member ) +1 )  %  (modulus));  \ 

}  else  if  ( (tm_member)  >=  (modulus))  {  \ 
tm_carry  +=  (tm_member)  /  (modulus) ;  \ 
tm_member  =  (tm_member)  %  (modulus) ;  \ 


//  Length  of  month  'm'  (0  ..  11) 

fdefine  monthlen (m,  y)  ( ydays [ (m) +1 ]  -  ydays [m]  +  leapday  (m,  y) ) 

time_t  110  6_CALL_DECL 

mkgmtime ( struct  tm  *  psuTmTime) 

{ 

//  Accumulated  number  of  days  from  01- Jan  up  to  start  of  current  month, 
static  short  ydays []  = 

{ 

0,  31,  59,  90,  120,  151,  181,  212,  243,  273,  304,  334,  365 

}  ; 


int  years,  months,  days. 

hours , 

minutes. 

seconds; 

years  =  psuTmTime->tm 

year  + 

1900; 

// 

year  -  1900  ->  year 

months  =  psuTmTime->tm 

mon; 

// 

0. 

.11 

days  =  psuTmTime->tm 

mday  - 

1; 

// 

1 . 

.31  -> 

0.  .30 

hours  =  psuTmTime->tm 

hour  ; 

// 

0. 

.23 

minutes  =  psuTmTime->tm 

min; 

// 

0. 

.59 

seconds  =  psuTmTime->tm 

sec; 

// 

0. 

.61  in 

ANSI  C. 
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AD JUST_TM ( seconds,  minutes,  60) 

ADJUST_TM (minutes,  hours,  60) 

ADJUST_TM (hours,  days,  24) 

AD JUST_TM (months ,  years,  12) 

if  (days  <  0) 
do 

{ 

if  (--months  <  0) 

{ 

--years ; 
months  =  11; 

} 

days  +=  monthlen (months ,  years); 

}  while  (days  <  0) ; 

else 

while  (days  >=  monthlen (months ,  years)) 

{ 

days  -=  monthlen (months,  years); 
if  (++months  >=  12) 

{ 

++years; 
months  =  0; 

} 

}  //  end  while 

//  Restore  adjusted  values  in  tm  structure 
psuTmTime->tm_year  =  years  -  1900; 
psuTmTime->tm_mon  =  months; 
psuTmTime->tm_mday  =  days  +  1; 
psuTmTime->tm_hour  =  hours; 
psuTmTime->tm_min  =  minutes; 
psuTmTime->tm_sec  =  seconds; 

//  Set  'days'  to  the  number  of  days  into  the  year, 
days  +=  ydays [months ]  +  (months  >  1  &&  leap  (years)); 
psuTmTime->tm_yday  =  days; 

//  Now  calculate  'days'  to  the  number  of  days  since  Jan  1,  1970. 
days  =  (unsigned) days  +  365  *  (unsigned) (years  -  1970)  + 

(unsigned) (nleap  (years) ) ; 

psuTmTime->tm_wday  =  ( (unsigned) days  +  4)  %  7;  /*  Jan  1,  1970  was  Thursday.  */ 
psuTmTime->tm_isdst  =  0; 

if  (years  <  1970) 

return  (time_t)-l; 

return  (time_t) (86400L  *  days  +  3600L  *  hours  +  60L  *  minutes  +  seconds); 

} 
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APPENDIX  A-5  -  I106  DECODE  TIME.H 

/**************************************************************************** 

ilO 6_decode_time . h  - 
Copyright  (c)  2005  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#ifndef  _I106_DECODE_TIME_H 
#def ine  _I106_DECODE_TIME_H 

#include  "irigl06chl0.h" 

#ifdef  _ cplusplus 

extern  "C"  { 

#endif 

/* 

*  Macros  and  definitions 

*  _ 

*/ 

typedef  enum 
{ 


1106  TIMEFMT  IRIG  B 

=  0x00, 

1106  TIMEFMT  IRIG  A 

=  0x01, 

1106  TIMEFMT  IRIG  G 

=  0x02, 

1106  TIMEFMT  INT  RTC 

=  0x03, 

1106  TIMEFMT  GPS  UTC 

=  0x04, 

1106  TIMEFMT  GPS  NATIVE 
}  EnI106TimeFmt; 

=  0x05, 

A-5-1 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


/* 

*  Data  structures 


*/ 


/*  Time  Format  1  */ 

#if  defined (_MSCJVER) 
#pragma  pack (push) 

#pragma  pack(l) 

#endif 

//  Channel  specific  header 
typedef  struct 
{ 


uint32 

t 

uTimeSrc 

4; 

// 

Time 

source 

uint32 

t 

uTimeFmt 

4; 

// 

Time 

format 

uint32 

t 

bLeapYear 

1; 

// 

Leap 

year 

uint32 

t 

uDateFmt 

1; 

// 

Date 

format 

uint32 

t 

uReserved2 

2; 

uint32 

t 

uReserved3 

16; 

#if  ! defined ( _ GNUC _ ) 

}  SuTimeFl_ChanSpec; 

#else 

}  _ attribute _  ( (packed) )  SuTimeFl^ChanSpec; 

#endif 

//  Time  message  -  Day  format 
typedef  struct 
{ 


uintl 6 

t 

uTmn 

4; 

// 

Tens  of  milliseconds 

uintl 6 

t 

uHmn 

4; 

// 

Hundreds  of  milliseconds 

uintl 6 

t 

uSn 

4; 

// 

Units  of  seconds 

uintl 6 

t 

uTSn 

3; 

// 

Tens  of  seconds 

uintl 6 

t 

Reservedl 

1; 

// 

0 

uintl 6 

t 

uMn 

4; 

// 

Units  of  minutes 

uintl 6 

t 

uTMn 

3; 

// 

Tens  of  minutes 

uintl 6 

t 

Reserved2 

1; 

// 

0 

uintl 6 

t 

uHn 

4; 

// 

Units  of  hours 

uintl 6 

t 

uTHn 

2; 

// 

Tens  of  Hours 

uintl 6 

t 

Reserved3 

2; 

// 

0 

uintl 6 

t 

uDn 

4; 

// 

Units  of  day  number 

uintl 6 

t 

uTDn 

4; 

// 

Tens  of  day  number 

uintl 6 

t 

uHDn 

2; 

// 

Hundreds  of  day  number 

uintl 6 

t 

Reserved4 

6; 

// 

0 

#if  ! defined ( _ GNUC _ ) 

}  SuTime_MsgDayFmt; 

#else 

}  _ attribute _  ( (packed) )  SuTime_MsgDayFmt; 

#endif 

//  Time  message  -  DMY  format 
typedef  struct 
{ 


uintl 6 

t 

uTmn 

4; 

// 

Tens  of  milliseconds 

uintl 6 

t 

uHmn 

4; 

// 

Hundreds  of  milliseconds 

uintl 6 

t 

uSn 

4; 

// 

Units  of  seconds 

uintl 6 

t 

uTSn 

3; 

// 

Tens  of  seconds 

uintl 6 

t 

Reservedl 

1; 

// 

0 
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uintl 6 

t 

uMn 

4; 

// 

Units  of  minutes 

uintl 6 

t 

uTMn 

3; 

// 

Tens  of  minutes 

uintl 6 

t 

Reserved2 

1; 

// 

0 

uintl 6 

t 

uHn 

4; 

// 

Units  of  hours 

uintl 6 

t 

uTHn 

2; 

// 

Tens  of  Hours 

uintl 6 

t 

Reserved3 

2; 

// 

0 

uintl 6 

t 

uDn 

4; 

// 

Units  of  day  number 

uintl 6 

t 

uTDn 

4; 

// 

Tens  of  day  number 

uintl 6 

t 

uOn 

4; 

// 

Units  of  month  number 

uintl 6 

t 

uTOn 

1; 

// 

Tens  of  month  number 

uintl 6 

t 

Reserved4 

3; 

// 

0 

uintl 6 

t 

uYn 

4; 

// 

Units  of  year  number 

uintl 6 

t 

uTYn 

4; 

// 

Tens  of  year  number 

uintl 6 

t 

uHYn 

4; 

// 

Hundreds  of  year  number 

uintl 6 

t 

uOYn 

2; 

// 

Thousands  of  year  number 

uintl 6 

t 

Reserved5 

2; 

// 

0 

#if  ! defined ( _ GNUC _ ) 

}  SuTime_MsgDmyFmt; 

#else 

}  _ attribute _  ( (packed) )  SuTime_MsgDmyFmt; 

fendif 

#if  defined (_MSC_VER) 

#pragma  pack (pop) 

#endif 

/* 

*  Function  Declaration 

*  _ 

*/ 

EnI106Status  I106_CALL_DECL 

enll 06_Decode_TimeFl (SuI106Chl OHeader 

void 

SuIrigl06Time 

EnI106Status  I106_CALL_DECL 

enI106_Encode_TimeFl (SuI106Chl0Header  *  psuHeader, 

unsigned  int  uExtTime, 

unsigned  int  uFmtTime, 

unsigned  int  uFmtDate, 

SuIrigl06Time  *  psuTime, 

void  *  pvBuf f TimeFl ) ; 

#ifdef  _ cplusplus 

} 

fendif 

fendif 


*  psuHeader, 

*  pvBuff, 

*  psuTime) ; 
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APPENDIX  A-6  -  I106  DECODE  TIME.C 

/**************************************************************************** 

il06_decode_time. c  - 
Copyright  (c)  2005  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <string.h> 

#include  <time.h> 

#include  <sys/types . h> 

#include  <sys/timeb . h> 

#if  defined (_WIN32 ) 

#include  <windows.h>  //  For  FILETIME 

#endif 

#include  "stdint.h" 

#include  "irigl06chl0.h" 

#include  "il06_time.h" 

#include  "il06  decode  time.h" 


/* 

*  Macros  and  definitions 

*  _ 

*/ 
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/* 

*  Data  structures 


*/ 

Day  and  Month 


//  Month  0-11 
//  Day  of  month  1-31 


/* 

*  Module  data 


*/ 


//  Day  of  Year  to 
typedef  struct 
{ 

int  iMonth; 
int  iDay; 

}  SuDOY2DM; 


//  SuTimeRef  m  suCurrRef Time ; 


//  Current  value  of  TRIG  reference  time 


//  These  structures  are  used  to  convert  from  day  of  the  year  format  to 
//  day  and  month.  One  is  for  normal  years  and  the  other  is  for  leap  years. 
//  The  values  and  index  are  of  the  "struct  tm"  notion.  That  is,  the  day  of 
//  the  year  index  is  number  of  days  since  Jan  1st,  i.e.  Jan  1st  =  0.  For 
//  IRIG  time,  Jan  1st  =  1.  The  month  value  is  months  since  January,  i.e. 

//  Jan  =  0.  Don't  get  confused! 


SuDOY2DM  suDoy2DmNormal [ ] 


0, 

1}, 

{ 

0, 

2}, 

{ 

0, 

3}, 

{ 

0, 

4}, 

{ 

0, 

5}, 

{ 

0, 

6}, 

{ 

0, 

7}, 

{ 

0, 

8} 

0, 

9}, 

{ 

0, 

10}, 

{ 

0, 

11}, 

{ 

0, 

12}, 

{ 

0, 

13}, 

{ 

0, 

14}, 

{ 

0, 

15}, 

{ 

0, 

16} 

0, 

17}, 

{ 

0, 

18}, 

{ 

0, 

19}, 

{ 

0, 

20}, 

{ 

0, 

21}, 

{ 

0, 

22}, 

{ 

0, 

23}, 

{ 

0, 

24  } 

0, 

25}, 

{ 

0, 

26}, 

{ 

0, 

27}, 

{ 

0, 

28}, 

{ 

0, 

29}, 

{ 

0, 

30}, 

{ 

0, 

31}, 

{ 

1, 

1} 

1, 

2}, 

{ 

1, 

3}, 

{ 

1, 

4}, 

{ 

1, 

5}, 

{ 

1, 

6}, 

{ 

1, 

7}, 

{ 

1, 

8}, 

{ 

1, 

9} 

1, 

10}, 

{ 

1, 

11}, 

{ 

1, 

12}, 

{ 

1, 

13}, 

{ 

1, 

14}, 

{ 

1, 

15}, 

{ 

1, 

16}, 

{ 

1, 

17  } 

1, 

18}, 

{ 

1, 

19}, 

{ 

1, 

20}, 

{ 

1, 

21}, 

{ 

1, 

22}, 

{ 

1, 

23}, 

{ 

1, 

24}, 

{ 

1, 

25} 

1, 

26}, 

{ 

1, 

27}, 

{ 

1, 

28}, 

{ 

2, 

1}, 

{ 

2, 

2}, 

{ 

2, 

3}, 

{ 

2, 

4}, 

{ 

2, 

5} 

2, 

6}, 

{ 

2, 

7}, 

{ 

2, 

8}, 

{ 

2, 

9}, 

{ 

2, 

10}, 

{ 

2, 

11}, 

{ 

2, 

12}, 

{ 

2, 

13} 

2, 

14}, 

{ 

2, 

15}, 

{ 

2, 

16}, 

{ 

2, 

17}, 

{ 

2, 

18}, 

{ 

2, 

19}, 

{ 

2, 

20}, 

{ 

2, 

21 } 

2, 

22}, 

{ 

2, 

23}, 

{ 

2, 

24}, 

{ 

2, 

25}, 

{ 

2, 

26}, 

{ 

2, 

27}, 

{ 

2, 

28}, 

{ 

2, 

29} 

2, 

30}, 

{ 

2, 

31}, 

{ 

3, 

1}, 

{ 

3, 

2}, 

{ 

3, 

3}, 

{ 

3, 

4}, 

{ 

3, 

5}, 

{ 

3, 

6} 

3, 

7}, 

{ 

3, 

8}, 

{ 

3, 

9}, 

{ 

3, 

10}, 

{ 

3, 

11}, 

{ 

3, 

12}, 

{ 

3, 

13}, 

{ 

3, 

14  } 

3, 

15}, 

{ 

3, 

16}, 

{ 

3, 

17}, 

{ 

3, 

18}, 

{ 

3, 

19}, 

{ 

3, 

20}, 

{ 

3, 

21}, 

{ 

3, 

22} 

3, 

23}, 

{ 

3, 

24}, 

{ 

3, 

25}, 

{ 

3, 

26}, 

{ 

3, 

27}, 

{ 

3, 

28}, 

{ 

3, 

29}, 

{ 

3, 

30} 

4, 

1}, 

{ 

4, 

2}, 

{ 

4, 

3}, 

{ 

4, 

4}, 

{ 

4, 

5}, 

{ 

4, 

6}, 

{ 

4, 

7}, 

{ 

4, 

8} 

4, 

9}, 

{ 

4, 

10}, 

{ 

4, 

11}, 

{ 

4, 

12}, 

{ 

4, 

13}, 

{ 

4, 

14}, 

{ 

4, 

15}, 

{ 

4, 

16} 

4, 

17}, 

{ 

4, 

18}, 

{ 

4, 

19}, 

{ 

4, 

20}, 

{ 

4, 

21}, 

{ 

4, 

22}, 

{ 

4, 

23}, 

{ 

4, 

24  } 

4, 

25}, 

{ 

4, 

26}, 

{ 

4, 

27}, 

{ 

4, 

28}, 

{ 

4, 

29}, 

{ 

4, 

30}, 

{ 

4, 

31}, 

{ 

5, 

1} 

5, 

2}, 

{ 

5, 

3}, 

{ 

5, 

4}, 

{ 

5, 

5}, 

{ 

5, 

6}, 

{ 

5, 

7}, 

{ 

5, 

8}, 

{ 

5, 

9} 

5, 

10}, 

{ 

5, 

11}, 

{ 

5, 

12}, 

{ 

5, 

13}, 

{ 

5, 

14}, 

{ 

5, 

15}, 

{ 

5, 

16}, 

{ 

5, 

17  } 

5, 

18}, 

{ 

5, 

19}, 

{ 

5, 

20}, 

{ 

5, 

21}, 

{ 

5, 

22}, 

{ 

5, 

23}, 

{ 

5, 

24}, 

{ 

5, 

25} 

5, 

26}, 

{ 

5, 

27}, 

{ 

5, 

28}, 

{ 

5, 

29}, 

{ 

5, 

30}, 

{ 

6, 

1}, 

{ 

6, 

2}, 

{ 

6, 

3} 

6, 

4}, 

{ 

6, 

5}, 

{ 

6, 

6}, 

{ 

6, 

7}, 

{ 

6, 

8}, 

{ 

6, 

9}, 

{ 

6, 

10}, 

{ 

6, 

11 } 

6, 

12}, 

{ 

6, 

13}, 

{ 

6, 

14}, 

{ 

6, 

15}, 

{ 

6, 

16}, 

{ 

6, 

17}, 

{ 

6, 

18}, 

{ 

6, 

19} 

6, 

20}, 

{ 

6, 

21}, 

{ 

6, 

22}, 

{ 

6, 

23}, 

{ 

6, 

24}, 

{ 

6, 

25}, 

{ 

6, 

26}, 

{ 

6, 

27  } 

6, 

28}, 

{ 

6, 

29}, 

{ 

6, 

30}, 

{ 

6, 

31}, 

{ 

7, 

1}, 

{ 

7, 

2}, 

{ 

7, 

3}, 

{ 

7, 

4} 

7, 

5}, 

{ 

7, 

6}, 

{ 

7, 

7}, 

{ 

7, 

8}, 

{ 

7, 

9}, 

{ 

7, 

10}, 

{ 

7, 

11}, 

{ 

7, 

12  } 

7, 

13}, 

{ 

7, 

14}, 

{ 

7, 

15}, 

{ 

7, 

16}, 

{ 

7, 

17}, 

{ 

7, 

18}, 

{ 

7, 

19}, 

{ 

7, 

20} 

7, 

21}, 

{ 

7, 

22}, 

{ 

7, 

23}, 

{ 

7, 

24}, 

{ 

7, 

25}, 

{ 

7, 

26}, 

{ 

7, 

27}, 

{ 

7, 

28} 

7, 

29}, 

{ 

7, 

30}, 

{ 

7, 

31}, 

{ 

8, 

1}, 

{ 

8, 

2}, 

{ 

8, 

3}, 

{ 

8, 

4}, 

{ 

8, 

5} 

8, 

6}, 

{ 

8, 

7}, 

{ 

8, 

8}, 

{ 

8, 

9}, 

{ 

8, 

10}, 

{ 

8, 

11}, 

{ 

8, 

12}, 

{ 

8, 

13} 

8, 

14}, 

{ 

8, 

15}, 

{ 

8, 

16}, 

{ 

8, 

17}, 

{ 

8, 

18}, 

{ 

8, 

19}, 

{ 

8, 

20}, 

{ 

8, 

21 } 

8, 

22}, 

{ 

8, 

23}, 

{ 

8, 

24}, 

{ 

8, 

25}, 

{ 

8, 

26}, 

{ 

8, 

27}, 

{ 

8, 

28}, 

{ 

8, 

29} 

8, 

30}, 

{ 

9, 

1}, 

{ 

9, 

2}, 

{ 

9, 

3}, 

{ 

9, 

4}, 

{ 

9, 

5}, 

{ 

9, 

6}, 

{ 

9, 

7} 
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{  9, 

8}, 

{ 

9, 

9}, 

{ 

9, 

10}, 

{  9, 

11}, 

{  9, 

12}, 

{ 

9, 

13}, 

{  9, 

14}, 

{ 

9, 

15} 

{  9, 

16}, 

{ 

9, 

17}, 

{ 

9, 

18}, 

{  9, 

19}, 

{  9, 

20}, 

{ 

9, 

21}, 

{  9, 

22}, 

{ 

9, 

23} 

{  9, 

24}, 

{ 

9, 

25}, 

{ 

9, 

26}, 

{  9, 

27}, 

{  9, 

28}, 

{ 

9, 

29}, 

{  9, 

30}, 

{ 

9, 

31} 

{10, 

1}, 

{10, 

2}, 

{10, 

3}, 

{10, 

4}, 

{10, 

5}, 

{10, 

6}, 

{10, 

7}, 

{10, 

8} 

{10, 

9}, 

{10, 

10}, 

{10, 

11}, 

{10, 

12}, 

{10, 

13}, 

{10, 

14}, 

{10, 

15}, 

{10, 

16} 

{10, 

17}, 

{10, 

18}, 

{10, 

19}, 

{10, 

20}, 

{10, 

21}, 

{10, 

22}, 

{10, 

23}, 

{10, 

24  } 

{10, 

25}, 

{10, 

26}, 

{10, 

27}, 

{10, 

28}, 

{10, 

29}, 

{10, 

30}, 

{11, 

1}, 

{11, 

2} 

{11, 

3}, 

{11, 

4}, 

{11, 

5}, 

{11, 

6}, 

{11, 

7}, 

{11, 

8}, 

{11, 

9}, 

{11, 

10} 

{11, 

11}, 

{11, 

12}, 

{11, 

13}, 

{11, 

14}, 

{11, 

15}, 

{11, 

16}, 

{11, 

17}, 

{11, 

18} 

{11, 

19}, 

{11, 

20}, 

{11, 

21}, 

{11, 

22}, 

{11, 

23}, 

{11, 

24}, 

{11, 

25}, 

{11, 

26} 

{11, 

27}, 

{11, 

28}, 

{11, 

29}, 

{11, 

30}, 

{11, 

31} 

}  ; 

SuDOY2DM 

suDoy2DmLeap [ ] 

=  { 

{  o. 

1}, 

{ 

0, 

2}, 

{ 

0, 

3}, 

{  o. 

4}, 

{  o. 

5}, 

{ 

0, 

6}, 

{  o. 

7}, 

{ 

0, 

8} 

{  o. 

9}, 

{ 

0, 

10}, 

{ 

0, 

11}, 

{  o. 

12}, 

{  o. 

13}, 

{ 

0, 

14}, 

{  o. 

15}, 

{ 

0, 

16} 

{  o. 

17}, 

{ 

0, 

18}, 

{ 

0, 

19}, 

{  o. 

20}, 

{  o. 

21}, 

{ 

0, 

22}, 

{  o. 

23}, 

{ 

0, 

24  } 

{  o. 

25}, 

{ 

0, 

26}, 

{ 

0, 

27}, 

{  o. 

28}, 

{  o. 

29}, 

{ 

0, 

30}, 

{  o. 

31}, 

{ 

1, 

1} 

{  1, 

2}, 

{ 

1, 

3}, 

{ 

1, 

4}, 

{  1, 

5}, 

{  1, 

6}, 

{ 

1, 

7}, 

{  1, 

8}, 

{ 

1, 

9} 

{  1, 

10}, 

{ 

1, 

11}, 

{ 

1, 

12}, 

{  1, 

13}, 

{  1, 

14}, 

{ 

1, 

15}, 

{  1, 

16}, 

{ 

1, 

17  } 

{  1, 

18}, 

{ 

1, 

19}, 

{ 

1, 

20}, 

{  1, 

21}, 

{  1, 

22}, 

{ 

1, 

23}, 

{  1, 

24}, 

{ 

1, 

25} 

{  1, 

26}, 

{ 

1, 

27}, 

{ 

1, 

28}, 

{  1, 

29}, 

{  2, 

1}, 

{ 

2, 

2}, 

{  2, 

3}, 

{ 

2, 

4} 

{  2, 

5}, 

{ 

2, 

6}, 

{ 

2, 

7}, 

{  2, 

8}, 

{  2, 

9}, 

{ 

2, 

10}, 

{  2, 

11}, 

{ 

2, 

12  } 

{  2, 

13}, 

{ 

2, 

14}, 

{ 

2, 

15}, 

{  2, 

16}, 

{  2, 

17}, 

{ 

2, 

18}, 

{  2, 

19}, 

{ 

2, 

20} 

{  2, 

21}, 

{ 

2, 

22}, 

{ 

2, 

23}, 

{  2, 

24}, 

{  2, 

25}, 

{ 

2, 

26}, 

{  2, 

27}, 

{ 

2, 

28} 

{  2, 

29}, 

{ 

2, 

30}, 

{ 

2, 

31}, 

{  3, 

1}, 

{  3, 

2}, 

{ 

3, 

3}, 

{  3, 

4}, 

{ 

3, 

5} 

{  3, 

6}, 

{ 

3, 

7}, 

{ 

3, 

8}, 

{  3, 

9}, 

{  3, 

10}, 

{ 

3, 

11}, 

{  3, 

12}, 

{ 

3, 

13} 

{  3, 

14}, 

{ 

3, 

15}, 

{ 

3, 

16}, 

{  3, 

17}, 

{  3, 

18}, 

{ 

3, 

19}, 

{  3, 

20}, 

{ 

3, 

21 } 

{  3, 

22}, 

{ 

3, 

23}, 

{ 

3, 

24}, 

{  3, 

25}, 

{  3, 

26}, 

{ 

3, 

27}, 

{  3, 

28}, 

{ 

3, 

29} 

{  3, 

30}, 

{ 

4, 

1}, 

{ 

4, 

2}, 

{  4, 

3}, 

{  4, 

4}, 

{ 

4, 

5}, 

{  4, 

6}, 

{ 

4, 

7} 

{  4, 

8}, 

{ 

4, 

9}, 

{ 

4, 

10}, 

{  4, 

11}, 

{  4, 

12}, 

{ 

4, 

13}, 

{  4, 

14}, 

{ 

4, 

15} 

{  4, 

16}, 

{ 

4, 

17}, 

{ 

4, 

18}, 

{  4, 

19}, 

{  4, 

20}, 

{ 

4, 

21}, 

{  4, 

22}, 

{ 

4, 

23} 

{  4, 

24}, 

{ 

4, 

25}, 

{ 

4, 

26}, 

{  4, 

27}, 

{  4, 

28}, 

{ 

4, 

29}, 

{  4, 

30}, 

{ 

4, 

31} 

{  5, 

1}, 

{ 

5, 

2}, 

{ 

5, 

3}, 

{  5, 

4}, 

{  5, 

5}, 

{ 

5, 

6}, 

{  5, 

7}, 

{ 

5, 

8} 

{  5, 

9}, 

{ 

5, 

10}, 

{ 

5, 

11}, 

{  5, 

12}, 

{  5, 

13}, 

{ 

5, 

14}, 

{  5, 

15}, 

{ 

5, 

16} 

{  5, 

17}, 

{ 

5, 

18}, 

{ 

5, 

19}, 

{  5, 

20}, 

{  5, 

21}, 

{ 

5, 

22}, 

{  5, 

23}, 

{ 

5, 

24  } 

{  5, 

25}, 

{ 

5, 

26}, 

{ 

5, 

27}, 

{  5, 

28}, 

{  5, 

29}, 

{ 

5, 

30}, 

{  6, 

1}, 

{ 

6, 

2} 

{  6, 

3}, 

{ 

6, 

4}, 

{ 

6, 

5}, 

{  6, 

6}, 

{  6, 

7}, 

{ 

6, 

8}, 

{  6, 

9}, 

{ 

6, 

10} 

{  6, 

11}, 

{ 

6, 

12}, 

{ 

6, 

13}, 

{  6, 

14}, 

{  6, 

15}, 

{ 

6, 

16}, 

{  6, 

17}, 

{ 

6, 

18} 

{  6, 

19}, 

{ 

6, 

20}, 

{ 

6, 

21}, 

{  6, 

22}, 

{  6, 

23}, 

{ 

6, 

24}, 

{  6, 

25}, 

{ 

6, 

26} 

{  6, 

27}, 

{ 

6, 

28}, 

{ 

6, 

29}, 

{  6, 

30}, 

{  6, 

31}, 

{ 

7, 

1}, 

{  7, 

2}, 

{ 

7, 

3} 

{  7, 

4}, 

{ 

7, 

5}, 

{ 

7, 

6}, 

{  7, 

7}, 

{  7, 

8}, 

{ 

7, 

9}, 

{  7, 

10}, 

{ 

7, 

11} 

{  7, 

12}, 

{ 

7, 

13}, 

{ 

7, 

14}, 

{  7, 

15}, 

{  7, 

16}, 

{ 

7, 

17}, 

{  7, 

18}, 

{ 

7, 

19} 

{  7, 

20}, 

{ 

7, 

21}, 

{ 

7, 

22}, 

{  7, 

23}, 

{  7, 

24}, 

{ 

7, 

25}, 

{  7, 

26}, 

{ 

7, 

27  } 

{  7, 

28}, 

{ 

7, 

29}, 

{ 

7, 

30}, 

{  7, 

31}, 

{  8, 

1}, 

{ 

8, 

2}, 

{  8, 

3}, 

{ 

8, 

4} 

{  8, 

5}, 

{ 

8, 

6}, 

{ 

8, 

7}, 

{  8, 

8}, 

{  8, 

9}, 

{ 

8, 

10}, 

{  8, 

11}, 

{ 

8, 

12  } 

{  8, 

13}, 

{ 

8, 

14}, 

{ 

8, 

15}, 

{  8, 

16}, 

{  8, 

17}, 

{ 

8, 

18}, 

{  8, 

19}, 

{ 

8, 

20} 

{  8, 

21}, 

{ 

8, 

22}, 

{ 

8, 

23}, 

{  8, 

24}, 

{  8, 

25}, 

{ 

8, 

26}, 

{  8, 

27}, 

{ 

8, 

28} 

{  8, 

29}, 

{ 

8, 

30}, 

{ 

9, 

1}, 

{  9, 

2}, 

{  9, 

3}, 

{ 

9, 

4}, 

{  9, 

5}, 

{ 

9, 

6} 

{  9, 

7}, 

{ 

9, 

8}, 

{ 

9, 

9}, 

{  9, 

10}, 

{  9, 

11}, 

{ 

9, 

12}, 

{  9, 

13}, 

{ 

9, 

14  } 

{  9, 

15}, 

{ 

9, 

16}, 

{ 

9, 

17}, 

{  9, 

18}, 

{  9, 

19}, 

{ 

9, 

20}, 

{  9, 

21}, 

{ 

9, 

22} 

{  9, 

23}, 

{ 

9, 

24}, 

{ 

9, 

25}, 

{  9, 

26}, 

{  9, 

27}, 

{ 

9, 

28}, 

{  9, 

29}, 

{ 

9, 

30} 

{  9, 

31}, 

{10, 

1}, 

{10, 

2}, 

{10, 

3}, 

{10, 

4}, 

{10, 

5}, 

{10, 

6}, 

{10, 

7} 

{10, 

8}, 

{10, 

9}, 

{10, 

10}, 

{10, 

11}, 

{10, 

12}, 

{10, 

13}, 

{10, 

14}, 

{10, 

15} 

{10, 

16}, 

{10, 

17}, 

{10, 

18}, 

{10, 

19}, 

{10, 

20}, 

{10, 

21}, 

{10, 

22}, 

{10, 

23} 

{10, 

24}, 

{10, 

25}, 

{10, 

26}, 

{10, 

27}, 

{10, 

28}, 

{10, 

29}, 

{10, 

30}, 

{11, 

1} 

{11, 

2}, 

{11, 

3}, 

{11, 

4}, 

{11, 

5}, 

{11, 

6}, 

{11, 

7}, 

{11, 

8}, 

{11, 

9} 

{11, 

10}, 

{11, 

11}, 

{11, 

12}, 

{11, 

13}, 

{11, 

14}, 

{11, 

15}, 

{11, 

16}, 

{11, 

17} 

{11, 

18}, 

{11, 

19}, 

{11, 

20}, 

{11, 

21}, 

{11, 

22}, 

{11, 

23}, 

{11, 

24}, 

{11, 

25} 

{11, 

26}, 

{11, 

27}, 

{11, 

28}, 

Ul, 

29}, 

{11, 

30}, 

{11, 

31} 

}; 

A-6-3 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


/* 

*  Function  Declaration 


/ *  =======================================================================  * / 

//  Take  an  IRIG  FI  time  packet  and  decode  it  into  something  we  can  use 

EnI106Status  I106_CALL_DECL 

enI106_Decode_TimeFl (SuI106Chl0Header  *  psuHeader, 

void  *  pvBuff, 

SuIrigl06Time  *  psuTime) 

{ 

//  time_t  ITime; 

struct  tm  suTmTime; 

//  struct  timeval  suTvTime; 

SuTimeFl_ChanSpec  *  psuChanSpecTime; 

SuTime_MsgDmyFmt  *  psuTimeDmy; 

SuTime_MsgDayFmt  *  psuTimeDay; 

psuChanSpecTime  =  (SuTimeFl_ChanSpec  *)pvBuff; 

//  Time  in  Day  format 

//  HMMMMM. . . .  THIS  ISN'T  QUITE  RIGHT.  DID  THE  STANDARD  CHANGE??? 
if  (psuChanSpecTime->uDateFmt  ==  0) 

{ 

/ /  Make 

psuTimeDay  =  ( SuTime_MsgDayFmt  *) ((char  *)pvBuff  +  sizeof (SuTimeFl_ChanSpec) ) ; 
suTmTime . tm_sec  =  psuTimeDay->uTSn  *  10  +  psuTimeDay->uSn; 

suTmTime . tm_min  =  psuTimeDay->uTMn  *  10  +  psuTimeDay->uMn; 

suTmTime . tm_hour  =  psuTimeDay->uTHn  *  10  +  psuTimeDay->uHn; 

suTmTime . tm_yday  =  psuTimeDay->uHDn  *  100  +  psuTimeDay->uTDn  *  10  + 

psuTimeDay->uDn  -  1; 

suTmTime . tm_mday  =  suDoy2DmNormal [suTmTime . tm_yday] . iDay; 
suTmTime . tm_mon  =  suDoy2DmNormal [suTmTime . tm_yday] . iMonth; 
suTmTime . tm_year  =70;  //  i.e.  1970 

suTmTime . tm_isdst  =  0; 

psuTime->ulSecs  =  mkgmtime (SsuTmTime) ; 

psuTime->ulFrac  =  psuTimeDay->uHmn  *  1000000L  +  psuTimeDay->uTmn  *  100000L; 
psuTime->enFmt  =  I106_DATEFMT_DAY; 

} 

//  Time  in  DMY  format 
else 

{ 

psuTimeDmy  =  ( SuTime_MsgDmyFmt  *) ((char  *)pvBuff  +  sizeof (SuTimeFl_ChanSpec) ) ; 

suTmTime . tm_sec  =  psuTimeDmy->uTSn  *  10  +  psuTimeDmy->uSn ; 

suTmTime . tm_min  =  psuTimeDmy->uTMn  *  10  +  psuTimeDmy->uMn ; 

suTmTime . tm_hour  =  psuTimeDmy->uTHn  *  10  +  psuTimeDmy->uHn ; 

suTmTime . tm_yday  =  0; 

suTmTime . tm_mday  =  psuTimeDmy->uTDn  *  10  +  psuTimeDmy->uDn ; 

suTmTime . tm_mon  =  psuTimeDmy->uTOn  *  10  +  psuTimeDmy->uOn  -  1; 

suTmTime . tm_year  =  psuTimeDmy->uOYn  *  1000  +  psuTimeDmy->uHYn  *  100  + 
psuTimeDmy->uTYn  *  10  +  psuTimeDmy->uYn  -  1900; 

suTmTime . tm_isdst  =  0; 

psuTime->ulSecs  =  mkgmtime (SsuTmTime) ; 

psuTime->ulFrac  =  psuTimeDmy->uHmn  *  1000000L  +  psuTimeDmy->uTmn  *  100000L; 
psuTime->enFmt  =  I106_DATEFMT_DMY; 

} 

return  1106  OK; 
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} 


/* 


This  function  returns  the  day  of  the  year  that  corresponds  to  the  date  in 
the  input  parameter  dt . 


-  */ 

/* 

static  int  iDay_Of_Year ( struct  date  *ptDate) 

{ 

int  *paiLastDayOfMonth; 

/ /  Figure  out  leap  year 

if  ( (ptDate->da_year  %  4)  !=  0)  paiLastDayOfMonth  =  aiLastDayOfMonthNormal ; 

else  paiLastDayOfMonth  =  aiLastDayOfMonthLeapYear ; 

return  paiLastDayOfMonth [ptDate->da_mon-l ]  +  ptDate->da_day ; 

} 

*/ 


EnI106Status  I106_CALL_DECL 

enI106_Encode_TimeFl (SuI106Chl0Header 

unsigned  int 
unsigned  int 
unsigned  int 
SuIrigl06Time 
void 

{ 

//A  temporary  integer  to  decimate  to 
uint32_t  ulntDec; 

struct  tm  *  psuTmTime; 


*  psuHeader, 
uTimeSrc , 
uFmtTime , 
uFmtDate, 

*  psuTime, 

*  pvBuf f TimeFl ) 

get  BCD  factors 


typedef  struct 

{ 

SuTimeFl_ChanSpec  suChanSpec; 
union 
{ 

SuTime_MsgDayFmt  suDayFmt; 
SuTime_MsgDmyFmt  suDmyFmt; 
}  suMsg; 

}  SuMsgTimeFl; 


SuMsgTimeFl  *  psuTimeFl; 


SuTime_MsgDayFmt  *  psuDayFmt; 

SuTime_MsgDmyFmt  *  psuDmyFmt; 

//  Now,  after  creating  this  ubertime-structure  above,  create  a 
//  couple  of  pointers  to  make  the  code  below  simpler  to  read. 
psuTimeFl  =  (SuMsgTimeFl  *) pvBuf fTimeFl ; 
psuDayFmt  =  & (psuTimeFl->suMsg . suDayFmt) ; 
psuDmyFmt  =  & (psuTimeFl->suMsg . suDmyFmt) ; 

//  Zero  out  all  the  time  fields 

memset (psuTimeFl ,  0,  sizeof (SuTimeFl_ChanSpec) ) ; 

//  Break  time  down  to  DMY  HMS 

psuTmTime  =  gmtime ( ( time_t  * ) & (psuTime->ulSecs) ) ; 
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//  Make  channel  specific  data  word 
psuTimeFl->suChanSpec . uTimeSrc  =  uTimeSrc; 

psuTimeFl->suChanSpec . uTimeFmt  =  uFmtTime; 

psuTimeFl->suChanSpec . uDateFmt  =  uFmtDate; 

if  (psuTmTime->tm_year  %  4  ==  0) 

psuTimeFl->suChanSpec . bLeapYear  =  1; 

else 

psuTimeFl->suChanSpec . bLeapYear  =  0; 

//  Fill  in  day  of  year  format 
if  (uFmtDate  ==  0) 

{ 

//  Zero  out  all  the  time  fields 

memset (psuDayFmt,  0,  sizeof ( SuTime_MsgDayFmt) ) ; 

//  Set  the  various  time  fields 
ulntDec  =  psuTime->ulFrac  /  100000L; 
psuDayFmt->uTmn  =  (uintl6_t) (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDayFmt->uHmn)  /  10; 
psuDayFmt->uHmn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_sec; 

psuDayFmt->uSn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  (ulntDec  -  psuDayFmt->uSn)  /  10; 
psuDayFmt->uTSn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_min; 

psuDayFmt->uMn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  (ulntDec  -  psuDayFmt->uMn)  /  10; 
psuDayFmt->uTMn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_hour ; 
psuDayFmt->uHn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  (ulntDec  -  psuDayFmt->uHn)  /  10; 
psuDayFmt->uTHn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_yday  +  1; 
psuDayFmt->uDn  =  (uintl6_t)  (ulntDec  %  10)  ; 
ulntDec  =  (ulntDec  -  psuDayFmt->uDn)  /  10; 
psuDayFmt->uTDn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  (ulntDec  -  psuDayFmt->uTDn)  /  10; 
psuDayFmt->uHDn  =  (uintl6_t) (ulntDec  %  10) ; 

//  Set  the  data  length  in  the  header 
psuHeader->ulDataLen  = 

sizeof (SuTimeFl_ChanSpec)  +  sizeof ( SuTime_MsgDayFmt ) ; 

} 

//  Fill  in  day,  month,  year  format 
else 

{ 

//  Zero  out  all  the  time  fields 

memset (psuDmyFmt,  0,  sizeof ( SuTime_MsgDmyFmt) ) ; 

//  Set  the  various  time  fields 
ulntDec  =  psuTime->ulFrac  /  100000L; 
psuDmyFmt->uTmn  =  (uintl6_t) (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uHmn)  /  10; 
psuDmyFmt->uHmn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_sec; 

psuDmyFmt->uSn  =  (uintl6_t) (ulntDec  %  10); 
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ulntDec  =  (ulntDec  -  psuDmyFmt->uSn)  /  10; 
psuDmyFmt->uTSn  =  (uintl6_t)  (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_min; 

psuDmyFmt->uMn  =  (uintl6_t)  (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uMn)  /  10; 
psuDmyFmt->uTMn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_hour ; 
psuDmyFmt->uHn  =  (uintl6_t) (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uHn)  /  10; 
psuDmyFmt->uTHn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_mday ; 
psuDmyFmt->uDn  =  (uintl6_t)  (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uDn)  /  10; 
psuDmyFmt->uTDn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_mon  +  1; 
psuDmyFmt->uOn  =  (uintl6_t) (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uOn)  /  10; 
psuDmyFmt->uTOn  =  (uintl6_t) (ulntDec  %  10); 

ulntDec  =  psuTmTime->tm_year  +  1900; 
psuDmyFmt->uYn  =  (uintl6_t)  (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uYn)  /  10; 
psuDmyFmt->uTYn  =  (uintl6_t) (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uTYn)  /  10; 
psuDmyFmt->uHYn  =  (uintl6_t) (ulntDec  %  10); 
ulntDec  =  (ulntDec  -  psuDmyFmt->uHYn)  /  10; 
psuDmyFmt->uOYn  =  (uintl6_t) (ulntDec  %  10); 

//  Set  the  data  length  in  the  header 
psuHeader->ulDataLen  = 

sizeof (SuTimeFl_ChanSpec)  t  sizeof ( SuTime_MsgDmyFmt ) ; 

} 


//  Make  the  data  buffer  checksum  and  update  the  header 
uAddDataFillerChecksum (psuHeader ,  (unsigned  char  *)pvBuffTimeFl); 

return  I106_OK; 

} 
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APPENDIX  A- 7  -  I106  DECODE  TMATS.H 

/**************************************************************************** 

il06_decode_tmats .h  - 
Copyright  (c)  2005  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#ifndef  _I106_DECODE_TMATS_H 
#def ine  _I106_DECODE_TMATS_H 

#ifdef  _ cplusplus 

extern  "C"  { 

#endif 

/* 

*  Macros  and  definitions 

*  _ 

*/ 


/* 

*  Data  structures 


*/ 

//  Channel  specific  data  word 
// - 

#if  defined (_MSC_VER) 

#pragma  pack (push) 

#pragma  pack(l) 
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#endif 


typedef  PUBLIC  struct  Tmats_ChanSpec_S 
{ 


uint32  t 

iChl OVer 

:  8; 

// 

Recorder 

Ch  10  Version 

uint32  t 

bConf igChange 

:  1; 

// 

Recorder 

configuration 

uint32  t 
#if  !defined( 

}  SuTmats 
#else 

iReserved 

_ GNUC _ ) 

ChanSpec; 

:  23; 

// 

Reserved 

}  attribute  (  (packed) ) 

fendif 

SuTmats 

ChanSpec; 

changed 


#if  defined (_MSC_VER) 
#pragma  pack (pop) 
fendif 


//  B  Records 
// - 

typedef  PUBLIC  struct  SuBRecord_S 
{ 


int 

iRecordNum; 

// 

B-x 

char 

*  szDataLinkName; 

// 

B-x\DLN 

int 

iNumBuses ; 

// 

B-x\NBS\N 

struct  SuBRecord  S 

*  psuNextBRecord; 

}  SuBRecord; 

//  M  Records 
// - 

typedef  PUBLIC  struct  SuMRecord_S 
{ 


int 

iRecordNum; 

// 

M-x 

char 

* 

szDataSourcelD; 

// 

s 

1 

X 

M 

D 

char 

-k 

szDataLinkName; 

// 

M-x\BB\DLN 

char 

■k 

szBasebandSignalType; 

// 

M-x\BSGl 

struct  SuBRecord  S 

: k 

psuBRecord; 

// 

Corresponding  B  record 

struct  SuMRecord  S 

: k 

psuNextMRecord; 

// 

Used  to  keep  track  of  M  records 

}  SuMRecord; 

//  R  Records 
// - 

//  R  record  data  source 
typedef  PUBLIC  struct  SuRDataSource__S 
{ 


int 

iDataSourceNum; 

// 

R-x\XXX-n 

char 

* 

szDataSourcelD; 

// 

R-x\DSI-n 

char 

* 

szChannelDataType ; 

// 

R-x\CDT-n 

int 

iTrackNumber ; 

// 

R-x\TKl-n 

int 

bEnabled; 

// 

R-x\CHE-n 

struct 

SuMRecord  S 

* 

psuMRecord; 

// 

Corresponding  M  record 

struct 

SuRDataSource  S 

psuNextRDataSource; 

}  SuRDataSource; 

//  R  record 

typedef  PUBLIC  struct  SuRRecord_S 

{ 

int  iRecordNum;  //  R-x 
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char 

*  szDataSourcelD; 

//  R-x\ ID 

int 

iNumDataSources ; 

//  R-x\N 

SuRDataSource 

*  psuFirstDataSource; 

// 

struct  SuRRecord  S 

*  psuNextRRecord; 

//  Used  to  keep  track  of  R 

}  SuRRecord; 

//  G  Records 
// - 

//  G  record,  data  source 
typedef  PUBLIC  struct  SuGDataSource_S 
{ 


int 

iDataSourceNum; 

// 

G\XXX-n 

char 

-k 

szDataSourcelD; 

// 

G\DSI-n 

char 

: k 

szDataSourceType; 

// 

G\DST-n 

struct  SuRRecord  S 

■k 

psuRRecord; 

// 

Corresponding 

struct  SuGDataSource  S 

: k 

psuNextGDataSource; 

}  SuGDataSource; 

//  G  record 

typedef  PUBLIC  struct  GRecord 

r 

_s 

l 

char 

* 

szProgramName; 

// 

G\PN 

char 

* 

szIrigl06Rev; 

// 

G\106 

int 

iNumDataSources ; 

// 

G\ DS I \N 

SuGDataSource 

* 

psuFirstGDataSource; 

}  SuGRecord; 

//  Memory  linked  list 
// - 

//  Linked  list  that  keeps  track  of  malloc'ed  memory 
typedef  PUBLIC  struct  MemBlock_S 
{ 

void  *  pvMemBlock; 

struct  MemBlock_S  *  psuNextMemBlock; 

}  SuMemBlock; 

//  Decoded  TMATS  info 
// - 

typedef  PUBLIC  struct  SuTmatsInf o_S 
{ 


int 

iChlOVer; 

int 

bConfigChange; 

SuGRecord 

* 

psuFirstGRecord; 

SuRRecord 

* 

psuFirstRRecord; 

SuMRecord 

* 

psuFirstMRecord; 

SuBRecord 

* 

psuFirstBRecord; 

void 

* 

psuFirstTRecord; 

void 

* 

psuFirstPRecord; 

void 

* 

psuFirstDRecord; 

void 

psuFirstSRecord; 

void 

* 

psuFirstARecord; 

void 

* 

psuFirstCRecord; 

void 

* 

psuFirstHRecord; 

void 

* 

psuFirstVRecord; 

SuMemBlock 

* 

psuFirstMemBlock 

}  SuTmatsInfo; 

/* 

*  Function  Declaration 


records 
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~k 

*/ 


EnI106Status  I106_CALL_DECL 

en 1 1 0 6_Decode_Tmat  s ( Su 1 1 0  6 Chi 0 Header 
void 

SuTmatsInf o 


*  psuHeader, 

*  pvBuff, 

*  psuTmatsInfo) ; 


void  I106_CALL_DECL 

enll 06_Free_TmatsInf o ( SuTmatsInf o 


*  psuTmatsInfo) ; 


110 6_CALL_DECL  EnI106Status 

enI106_Encode_Tmats (SuI106Chl0Header 
void 
char 


*  psuHeader, 

*  pvBuff, 

*  SzTMATS) ; 


#ifdef  _ cplusplus 

} 

#endif 

#endif 
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APPENDIX  A-8  -  I106  DECODE  TMATS.C 

/**************************************************************************** 


il06_decode_tmats . c  - 
Copyright  (c)  2005  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 


*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 


#include 

#include 

#include 

#include 

#include 


<stdio . h> 
<stdlib . h> 
<string . h> 
<malloc . h> 
<assert . h> 


#include  "config.h" 
#include  "stdint.h" 


#include  "irigl06chl0.h" 
#include  "il06  decode  tmats.h" 


/****************************************************************************** 
Here's  how  this  module  decodes  and  stores  TMATS  data. 

Any  field  that  is  to  be  decoded  and  stored  must  have  a  corresponding  entry 
in  one  of  the  defined  data  structures.  In  other  words,  there  is  no  support 
for  storing  and  later  retrieving  arbitrary  TMATS  lines.  Maybe  that  would  have 
been  better,  but  for  now  only  TMATS  lines  that  are  understood  by  this  module 
will  be  stored. 

This  module  makes  no  assumptions  about  the  ordering,  numbering,  or 
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numbers  of  TMATS  lines.  Information  is  stored  in  linked  lists  that  are 
created  and  grow  as  needed.  For  now  there  is  the  assumption  that  there 
is  only  one  G  record,  but  there  may  be  multiples  of  other  records. 

There  is  a  linked  list  for  each  type  of  record  (except  the  one  and  only 
G  record) .  As  the  TMATS  lines  are  read  one  by  one,  the  info  is  decoded 
and  stored  in  the  appropriate  existing  record,  or  a  new  record  is  create 
if  necessary. 

After  all  TMATS  lines  are  read  and  decoded,  the  linked  lists  are  scanned 
and  connected  into  a  tree.  That  is,  R  records  are  connected  to  the 
corresponding  G,  M  records  are  connected  to  the  corresponding  R,  etc. 

When  done,  the  TMATS  info  is  organized  into  a  tree  similar  to  that  depicted 
in  IRIG  106  Chapter  9  (TMATS)  Figure  9-1  "Group  relationships". 

There  are  at  least  two  ways  to  use  this  information.  One  is  to  start  with 
the  top  level  G  record  and  walk  the  tree.  This  is  a  good  way  to  provide 
access  to  all  the  decoded  data,  for  example,  to  print  out  everything  in 
the  tree.  The  other  way  to  access  data  is  to  start  at  the  beginning  of 
one  of  the  linked  lists  of  records,  and  walk  the  linked  list.  This  might 
be  a  good  way  to  get  just  some  specific  data,  like  a  list  of  Channel  ID's 
for  1553IN  type  data  sources. 

******************************************************************************  I 


/* 

*  Macros  and  definitions 


*/ 

#define  CR  (13) 

#define  LF  (10) 

/* 

*  Data  structures 


*/ 


//  1553  bus  attributes 
// - 

/* 

*  Module  data 


*/ 


//  This  is  an  empty  string  that  text  fields  can  point  to  before 
//  they  get  a  value.  This  ensures  that  if  fields  don't  get  set  while 
//  reading  the  TMATS  record  they  will  point  to  something  benign, 
char  m_szEmpty[]  = 

static  SuTmatsInfo  *  m_psuTmatsInfo; 

/* 

*  Function  Declaration 


*/ 


int  bDecodeGLine (char  * 
int  bDecodeRLine (char  * 
int  bDecodeMLine  (char  * 
int  bDecodeBLine (char  * 


szCodeName, 

char 

* 

szDataltem, 

SuGRecord 

*  * 

szCodeName, 

char 

* 

szDataltem, 

SuRRecord 

*  * 

szCodeName, 

char 

* 

szDataltem, 

SuMRecord 

*  * 

szCodeName, 

char 

* 

szDataltem, 

SuBRecord 

*  * 

ppsuFirstGRec) 

ppsuFirstRRec) 

ppsuFirstMRec) 

ppsuFirstBRec) 
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SuRRecord  *  psuGetRRecord ( SuRRecord  **  ppsuFirstRRec,  int  iRIndex,  int  bMakeNew); 

SuMRecord  *  psuGetMRecord ( SuMRecord  **  ppsuFirstMRec,  int  iRIndex,  int  bMakeNew); 

SuBRecord  *  psuGetBRecord ( SuBRecord  **  ppsuFirstBRec,  int  iRIndex,  int  bMakeNew); 

SuGDataSource  *  psuGetGDataSource ( SuGRecord  *  psuGRec,  int  iDSIIndex,  int  bMakeNew) 
SuRDataSource  *  psuGetRDataSource ( SuRRecord  *  psuRRec,  int  iDSIIndex,  int  bMakeNew) 

void  vConnectRtoG ( SuGRecord  *  psuFir stGRecord,  SuRRecord  *  psuFir stRRecord) ; 
void  vConnectMtoR ( SuRRecord  *  psuFir stRRecord,  SuMRecord  *  psuFir stMRecord) ; 
void  vConnectBtoM ( SuMRecord  *  psuFir stMRecord,  SuBRecord  *  psuFir stBRecord) ; 

void  *  TmatsMalloc ( size_t  iSize) ; 

/ *  =======================================================================  * / 

/*  The  idea  behind  this  routine  is  to  read  the  TMATS  record,  parse  it,  and 

*  put  the  various  data  fields  into  a  tree  structure  that  can  be  used  later 

*  to  find  various  settings. 

*/ 

EnI106Status  I106_CALL_DECL 

enI106_Decode_Tmats (SuI106Chl0Header  *  psuHeader, 


r 

void  *  pvBuff, 

SuTmatsInfo  *  psuTmatsInfo) 

l 

unsigned  long 

ilnBuf f Idx; 

char 

* 

achlnBuf f ; 

char 

szLine  [2048] ; 

int 

iLineldx; 

char 

* 

szCodeName ; 

char 

szDataltem; 

int 

bParseError  ; 

SuTmats  ChanSpec 

* 

psuTmats  ChanSpec; 

//  Store  a  copy 

for 

module  wide  use 

m  psuTmatsInfo  = 

psuTmatsInfo; 

//  Initialize  the  TMATS  info  data  structure 
enI106_Free_TmatsInfo (psuTmatsInfo)  ; 

//  Decode  any  available  info  from  channel  specific  data  word 
switch  (psuHeader->ubyHdrVer ) 

{ 

case  0x03  :  //  106-07 

psuTmats_ChanSpec  =  (SuTmats_ChanSpec  *)pvBuff; 
psuTmatsInfo->iChlOVer  =  psuTmats_ChanSpec->iChlOVer; 

psuTmatsInfo->bConf igChange  =  psuTmats_ChanSpec->bConf igChange; 
break; 
default  : 

psuTmatsInfo->iChlOVer  =  0x00; 

psuTmatsInfo->bConfigChange  =  0x00; 
break; 

} 


//  Initialize  the  first  (and  only,  for  now)  G  record 

psuTmatsInfo->psuFirstGRecord  =  (SuGRecord  *) TmatsMalloc ( sizeof (SuGRecord) ) ; 
psuTmatsInfo->psuFirstGRecord->szProgramName  =  m_szEmpty; 

psuTmatsInfo->psuFirstGRecord->szIrigl06Rev  =  m_szEmpty; 

psuTmatsInfo->psuFirstGRecord->iNumDataSources  =  0; 

psuTmatsInfo->psuFirstGRecord->psuFirstGDataSource  =  NULL; 

//  Buffer  starts  past  Channel  Specific  Data 
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achlnBuff  =  (char  *)pvBuff; 

ilnBuffldx  =  4; 

//  Loop  until  we  get  to  the  end  of  the  buffer 
while  (bTRUE) 

{ 

//  If  at  the  end  of  the  buffer  then  break  out  of  the  big  loop 
if  (ilnBuffldx  >=  psuHeader->ulDataLen) 
break; 

//  Fill  a  local  buffer  with  one  line 
// - 

//  Initialize  input  line  buffer 
szLine [0]  =  ' \0 ' ; 
iLineldx  =  0; 

//  Read  from  buffer  until  complete  line 
while  (bTRUE) 

{ 

//  If  at  the  end  of  the  buffer  then  break  out 
if  (ilnBuffldx  >=  psuHeader->ulDataLen) 
break; 

//  If  line  terminator  and  line  buffer  not  empty  then  break  out 
if  ( (achlnBuff [ilnBuffldx]  ==  CR)  | | 

(achlnBuff [ilnBuffldx]  ==  LF) ) 

{ 

if  ( strlen  ( szLine)  !=  0) 
break; 

}  //  end  if  line  terminator 

//  Else  copy  next  character  to  line  buffer 
else 

{ 

szLine [ iLineldx]  =  achlnBuff [ilnBuffldx] ; 
if  (iLineldx  <  2048) 
iLineIdx++ ; 

szLine [ iLineldx]  =  ' \ 0 ' ; 

} 


//  Next  character  from  buffer 
ilnBuf fldx++; 

}  //  end  while  filling  complete  line 

//  Decode  the  TMATS  line 
// - 

//  Go  ahead  and  split  the  line  into  left  hand  and  right  hand  sides 
szCodeName  =  strtok ( szLine,  ":"); 
szDataltem  =  strtok(NULL,  ";"); 

//  If  errors  tokenizing  the  line  then  skip  over  them 
if  ( (szCodeName  ==  NULL)  | |  (szDataltem  ==  NULL) ) 
continue ; 

//  Determine  and  decode  different  TMATS  types 
switch  (szCodeName [0] ) 

{ 

case  'G'  :  //  General  Information 

bParseError  =  bDecodeGLine (szCodeName, 
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szDataltem, 

SpsuTmatsInf o->psuFirstGRecord)  ; 

break; 

case  'B'  ;  //  Bus  Data  Attributes 

bParseError  =  bDecodeBLine (szCodeName, 

szDataltem, 

SpsuTmatsInf o->psuFirstBRecord) ; 

break; 

case  'R'  :  //  Tape/Storage  Source  Attributes 
bParseError  =  bDecodeRLine (szCodeName, 

szDataltem, 

SpsuTmatsInf o->psuFirstRRecord) ; 

break; 

case  'T'  ;  //  Transmission  Attributes 

break; 

case  'M'  ;  //  Multiplexing/Modulation  Attributes 

bParseError  =  bDecodeMLine (szCodeName, 

szDataltem, 

SpsuTmatsInf o->psuFirstMRecord) ; 

break; 

case  'P'  ;  //  PCM  Format  Attributes 
break; 

case  'D'  ;  //  PCM  Measurement  Description 

break; 

case  'S'  :  //  Packet  Format  Attributes 
break; 

case  'A'  ;  //  PAM  Attributes 

break; 

case  'C'  :  //  Data  Conversion  Attributes 

break; 

case  'H'  ;  //  Airborne  Hardware  Attributes 
break; 

case  'V'  ;  //  Vendor  Specific  Attributes 

break; 

default  ; 
break; 

}  //  end  decoding  switch 

}  //  end  looping  forever  on  reading  TMATS  buffer 
//  Now  link  the  various  records  together  into  a  tree 

vConnectRtoG (psuTmatsInf o->psuFirstGRecord,  psuTmatsInf o->psuFirstRRecor 
vConnectMtoR (psuTmatsInf o->psuFirstRRecord,  psuTmatsInf o->psuFirstMRecor 
vConnectBtoM (psuTmatsInf o->psuFirstMRecord,  psuTmatsInf o->psuFirstBRecor 

m_psuTmatsInfo  =  NULL; 

return  I106_OK; 

} 
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/* - 

*  G  Records 


*/ 


int 


bDecodeGLine (char  *  szCodeName, 

{ 


char 

int 

int 

SuGRecord 

SuGDataSource 


*  szCodeField; 
iTokens ; 
iDSI Index; 

*  psuGRec; 

*  psuDataSource; 


char  *  szDataltem,  SuGRecord  **  ppsuGRecord) 


//  See  which  G  field  it  is 
szCodeField  =  strtok (szCodeName,  "\\") ; 
assert ( szCodeField [ 0 ]  ==  ' G ' )  ; 


//  Get  the  G  record 
psuGRec  =  *ppsuGRecord; 

szCodeField  =  strtok (NULL,  "\\")  ; 


/ /  PN  -  Program  Name 

if  ( strcasecmp ( szCodeField,  "PN")  ==  0) 

{ 

psuGRec->szProgramName  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) ; 
assert  (psuGRec->szProgramName  !=  NULL); 
strcpy (psuGRec->szProgramName,  szDataltem) ; 

} 


//  106  -  IRIG  106  rev  level 

else  if  (strcasecmp (szCodeField,  "106")  ==  0) 

{ 

psuGRec->szIrigl06Rev  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) ; 
assert  (psuGRec->szIrigl06Rev  !=  NULL); 
strcpy (psuGRec->szIrigl06Rev,  szDataltem) ; 

}  //  end  if  106 

//  DSI  -  Data  source  identifier  info 

else  if  (strcasecmp (szCodeField,  "DSI")  ==  0) 

{ 

szCodeField  =  strtok(NULL,  "\\") ; 

//  N  -  Number  of  data  sources 
if  (strcasecmp (szCodeField,  "N")  ==  0) 

psuGRec->iNumDataSources  =  atoi ( szDataltem) ; 

}  //  end  if  DSI 

//  DSI-n  -  Data  source  identifiers 

else  if  (strncasecmp (szCodeField,  "DSI-",4)  ==  0) 

{ 

iTokens  =  sscanf (szCodeField,  "%*3c-%i",  SiDSIIndex) ; 
if  (iTokens  ==  1) 

{ 

psuDataSource  =  psuGetGDataSource (psuGRec,  iDSIIndex,  bTRUE) ; 
assert  (psuDataSource  !=  NULL) ; 

psuDataSource->szDataSourceID  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) 
assert  (psuDataSource->szDataSourceID  !=  NULL) ; 
strcpy (psuDataSource->szDataSourceID,  szDataltem) ; 

}  //  end  if  DSI  Index  found 
}  //  end  if  DSI-n 
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//  DST-n  -  Data  source  type 

else  if  (strncasecmp (szCodeField,  "DST-",4)  ==  0) 

{ 

iTokens  =  sscanf (szCodeField,  "%*3c-%i",  SiDSIIndex) ; 
if  (iTokens  ==  1) 

{ 

psuDataSource  =  psuGetGDataSource (psuGRec,  iDSIIndex,  bTRUE); 
assert (psuDataSource  !=  NULL); 

psuDataSource->szDataSourceType  =  (char  * ) TmatsMalloc ( str len ( szDataltem) +1 ) 
assert (psuDataSource->szDataSourceType  !=  NULL); 
strcpy (psuDataSource->szDataSourceType,  szDataltem) ; 

}  //  end  if  DSI  Index  found 
}  //  end  if  DST-n 


return  0; 

} 


/*  -  */ 

//  Return  the  G  record  Data  Source  record  with  the  given  index  or 
//  make  a  new  one  if  necessary. 

SuGDataSource  *  psuGetGDataSource ( SuGRecord  *  psuGRecord,  int  iDSIIndex,  int  bMakeNew) 

{ 

SuGDataSource  **ppsuDataSrc  =  & (psuGRecord- >psuFirstGDataSource) ; 

//  Walk  the  linked  list  of  data  sources,  looking  for  a  match  or 
//  the  end  of  the  list 
while  (bTRUE) 

{ 

//  If  record  pointer  in  linked  list  is  null  then  exit 
if  ( *ppsuDataSrc  ==  NULL) 

{ 

break; 

} 

//  If  the  data  source  number  matched  then  record  found,  exit 
if  ( ( *ppsuDataSrc) ->iDataSourceNum  ==  iDSIIndex) 

{ 

break; 

} 


//  Not  found  but  next  record  exists  so  make  it  our  current  pointer 
ppsuDataSrc  =  & (  ( *ppsuDataSrc) ->psuNextGDataSource) ; 

}  //  end 


//  If  no  record  found  then  put  a  new  one  on  the  end  of  the  list 
if  ( ( *ppsuDataSrc  ==  NULL)  &&  (bMakeNew  ==  bTRUE) ) 

{ 

//  Allocate  memory  for  the  new  record 

*ppsuDataSrc  =  (SuGDataSource  *) TmatsMalloc (sizeof (SuGDataSource)  )  ; 
assert  (*ppsuDataSrc  !=  NULL); 


//  Now  initialize  some  fields 
(*ppsuDataSrc) ->iDataSourceNum 
(*ppsuDataSrc) ->szDataSourceID 
(*ppsuDataSrc) ->szDataSourceType 
(*ppsuDataSrc) ->psuRRecord 
(*ppsuDataSrc) ->psuNextGDataSource 
} 


iDSIIndex; 
m_s z Empty ; 
m_s z Empty  ; 
NULL  ; 

NULL  ; 


return  *ppsuDataSrc; 
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} 


/* - 

*  R  Records 


*/ 


int 


bDecodeRLine (char  *  szCodeName, 

{ 


char 

int 

int 

int 

SuRRecord 

SuRDataSource 


*  szCodeField; 
iTokens ; 
iRIdx; 

iDSI Index; 

*  psuRRec; 

*  psuDataSource; 


char  *  szDataltem,  SuRRecord  **  ppsuFir stRRecord) 


//  See  which  R  field  it  is 
szCodeField  =  strtok (szCodeName,  "\\") ; 
assert ( szCodeField [ 0 ]  ==  ' R ' )  ; 


/ /  Get  the  R  record  index  number 

iTokens  =  sscanf (szCodeField,  "%*lc-%i",  SiRIdx) ; 
if  (iTokens  ==  1) 

{ 

psuRRec  =  psuGetRRecord (ppsuFirstRRecord,  iRIdx,  bTRUE); 
assert (psuRRec  !=  NULL); 


else 

return  1; 

szCodeField  =  strtok (NULL,  "\\") ; 

//ID  -  Data  source  ID 

if  (strcasecmp (szCodeField,  "ID")  ==  0) 

{ 

psuRRec->szDataSourceID  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) ; 
assert (psuRRec->szDataSourceID  !=  NULL) ; 
strcpy (psuRRec->szDataSourceID,  szDataltem) ; 

}  //  end  if  N 

//  N  -  Number  of  data  sources 

else  if  (strcasecmp (szCodeField,  "N")  ==  0) 

{ 

psuRRec->iNumDataSources  =  atoi ( szDataltem) ; 

}  //  end  if  N 

//  DSI-n  -  Data  source  identifier 

else  if  (strncasecmp (szCodeField,  "DSI-",4)  ==  0) 

{ 

iTokens  =  sscanf (szCodeField,  "%*3c-%i",  SiDSIIndex) ; 
if  (iTokens  ==  1) 

{ 

psuDataSource  =  psuGetRDataSource (psuRRec,  iDSIIndex,  bTRUE); 
assert (psuDataSource  !=  NULL) ; 

psuDataSource->szDataSourceID  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) 
assert (psuDataSource->szDataSourceID  !=  NULL) ; 
strcpy (psuDataSource->szDataSourceID,  szDataltem) ; 

}  //  end  if  DSI  Index  found 

else 

return  1; 

}  //  end  if  DSI-n 
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//  CDT-n/DST-n  -  Channel  data  type 

//  A  certain  vendor  who  will  remain  nameless  (mainly  because  I  don't 
//  know  which  one)  encodes  the  channel  data  type  as  a  Data  Source 
//  Type.  This  appears  to  be  incorrect  according  to  the  Chapter  9 
//  spec  but  can  be  readily  found  in  Chapter  10  data  files, 
else  if  (  ( strncasecmp ( szCodeField,  "CDT-",4)  ==  0)  || 

( strncasecmp ( szCodeField,  "DST-",4)  ==  0)) 

{ 

iTokens  =  sscanf (szCodeField,  "%*3c-%i",  SiDSIIndex) ; 
if  (iTokens  ==  1) 

{ 

psuDataSource  =  psuGetRDataSource (psuRRec,  iDSIIndex,  bTRUE); 
assert (psuDataSource  !=  NULL); 

psuDataSource->szChannelDataType  =  (char  * ) TmatsMalloc ( strlen ( szDatal tern) +1 ) 
assert (psuDataSource->szChannelDataType  !=  NULL); 
strcpy (psuDataSource->szChannelDataType,  szDataltem) ; 

}  //  end  if  DSI  Index  found 

else 

return  1; 

}  //  end  if  DST-n 

//  TKl-n  -  Track  number  /  Channel  number 

else  if  (strncasecmp (szCodeField,  "TKl-",4)  ==  0) 

{ 

iTokens  =  sscanf  (szCodeField,  "%*3c-%i",  SiDSIIndex) ; 
if  (iTokens  ==  1) 

{ 

psuDataSource  =  psuGetRDataSource (psuRRec,  iDSIIndex,  bTRUE); 
assert (psuDataSource  !=  NULL); 

psuDataSource->iTrackNumber  =  atoi ( szDataltem) ; 

}  //  end  if  DSI  Index  found 

else 

return  1; 

}  //  end  if  TKl-n 

//  CHE-n  -  Channel  Enabled 

else  if  (strncasecmp (szCodeField,  "CHE-",4)  ==  0) 

{ 

iTokens  =  sscanf  (szCodeField,  "%*3c-%i",  SiDSIIndex) ; 
if  (iTokens  ==  1) 

{ 

psuDataSource  =  psuGetRDataSource (psuRRec,  iDSIIndex,  bTRUE); 
assert (psuDataSource  !=  NULL); 

psuDataSource->bEnabled  =  (strncasecmp (szDataltem,  "T",l)  ==  0) ; 

}  //  end  if  DSI  Index  found 

else 

return  1; 

}  //  end  if  CHE-n 

return  0; 

} 


/*  -  */ 

SuRRecord  *  psuGetRRecord ( SuRRecord  **  ppsuFirstRRecord,  int  iRIndex,  int  bMakeNew) 

{ 

SuRRecord  **  ppsuCurrRRec  =  ppsuFirstRRecord; 

//  Loop  looking  for  matching  index  number  or  end  of  list 
while  (bTRUE) 
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{ 

//  Check  for  end  of  list 
if  ( *ppsuCurrRRec  ==  NULL) 
break; 

//  Check  for  matching  index  number 
if  ( (*ppsuCurrRRec) ->iRecordNum  ==  iRIndex) 
break; 

//  Move  on  to  the  next  record  in  the  list 
ppsuCurrRRec  =  & ( ( *ppsuCurrRRec) ->psuNextRRecord) ; 
} 


//  If  no  record  found  then  put  a  new  one  on  the  end  of  the  list 
if  ( ( *ppsuCurrRRec  ==  NULL)  &&  (bMakeNew  ==  bTRUE) ) 

{ 

//  Allocate  memory  for  the  new  record 

*ppsuCurrRRec  =  (SuRRecord  * ) TmatsMalloc ( sizeof (SuRRecord) ) ; 
assert  (*ppsuCurrRRec  !=  NULL) ; 


//  Now  initialize  some  fields 
( *ppsuCurrRRec ) ->iRecordNum 
( *ppsuCurrRRec ) ->szDataSourceID 
( * ppsuCurrRRec ) ->iNumDataSources 
( * ppsuCurrRRec )- >psu First Da taSource 
( *ppsuCurrRRec ) ->psuNextRRecord 
} 


iRIndex; 
m_s z Empty; 
0; 

NULL; 

NULL; 


return  *ppsuCurrRRec ; 

} 


/*  -  */ 

//  Return  the  R  record  Data  Source  record  with  the  given  index  or 
//  make  a  new  one  if  necessary. 

SuRDataSource  *  psuGetRDataSource ( SuRRecord  *  psuRRecord,  int  iDSIIndex,  int  bMakeNew) 

{ 

SuRDataSource  **  ppsuDataSrc  =  & (psuRRecord->psuFirstDataSource) ; 

//  Walk  the  linked  list  of  data  sources,  looking  for  a  match  or 
//  the  end  of  the  list 
while  (bTRUE) 

{ 

//  If  record  pointer  in  linked  list  is  null  then  exit 
if  ( *ppsuDataSrc  ==  NULL) 

{ 

break; 

} 

//  If  the  data  source  number  matched  then  record  found,  exit 
if  ( ( *ppsuDataSrc) ->iDataSourceNum  ==  iDSIIndex) 

{ 

break; 

} 

//  Not  found  but  next  record  exists  so  make  it  our  current  pointer 
ppsuDataSrc  =  & ( (*ppsuDataSrc) ->psuNextRDataSource)  ; 

}  //  end 

//  If  no  record  found  then  put  a  new  one  on  the  end  of  the  list 
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if  ( ( *ppsuDataSrc  ==  NULL)  &&  (bMakeNew  ==  bTRUE) ) 

{ 

//  Allocate  memory  for  the  new  record 

*ppsuDataSrc  =  ( SuRDataSource  * ) TmatsMalloc ( sizeof ( SuRDataSource) ) ; 
assert (*ppsuDataSrc  !=  NULL) ; 


//  Now  initialize  some  fields 
(*ppsuDataSrc) ->iDataSourceNum 
(*ppsuDataSrc) ->szDataSourceID 
(*ppsuDataSrc) ->szChannelDataType 
( *ppsuDataSrc) ->iTrackNumber 
(*ppsuDataSrc) ->psuMRecord 
(*ppsuDataSrc) ->psuNextRDataSource 
} 


iDSI Index; 
m_s z Empty ; 
m_s z Empty  ; 

0; 

NULL  ; 

NULL  ; 


return  *ppsuDataSrc; 

} 


/* - 

*  M  Records 


*/ 


int 


bDecodeMLine (char  *  szCodeName, 

{ 


char 

int 

int 

SuMRecord 


*  szCodeField; 
iTokens ; 
iRIdx; 

*  psuMRec; 


char  *  szDataltem,  SuMRecord  **  ppsuFir stMRecord) 


//  See  which  M  field  it  is 
szCodeField  =  strtok (szCodeName,  "\\") ; 
assert  ( szCodeField [ 0 ]  ==  'M'); 


/ /  Get  the  M  record  index  number 

iTokens  =  sscanf (szCodeField,  "%*lc-%i",  SiRIdx) ; 
if  (iTokens  ==  1) 

{ 

psuMRec  =  psuGetMRecord (ppsuFirstMRecord,  iRIdx,  bTRUE); 
assert (psuMRec  !=  NULL) ; 


else 

return  1; 

szCodeField  =  strtok (NULL,  "\\") ; 

//ID  -  Data  source  ID 

if  (strcasecmp (szCodeField,  "ID")  ==  0) 

{ 

psuMRec->szDataSourceID  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) ; 
assert (psuMRec->szDataSourceID  !=  NULL) ; 
strcpy (psuMRec->szDataSourceID,  szDataltem) ; 

}  //  end  if  ID 

//  BSG1  -  Baseband  signal  type 

else  if  (strcasecmp (szCodeField,  "BSG1")  ==  0) 

{ 

psuMRec->szBasebandSignalType  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) ; 
assert (psuMRec->szBasebandSignalType  !=  NULL) ; 
strcpy (psuMRec->szBasebandSignalType,  szDataltem) ; 

}  //  end  if  BSG1 
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//  BB\DLN  -  Data  link  name 

else  if  (strncasecmp (szCodeField,  "BB",2)  ==  0) 

{ 

szCodeField  =  strtok(NULL,  "\\")  ; 

//  DLN  -  Data  link  name 

if  ( strcasecmp ( szCodeField,  "DLN")  ==  0) 

{ 

psuMRec->szDataLinkName  =  (char  * ) TmatsMalloc ( strlen ( szDataltem) +1 ) ; 
assert (psuMRec->szDataLinkName  !=  NULL); 
strcpy (psuMRec->szDataLinkName,  szDataltem) ; 

} 

}  //  end  if  BB\DLN 


return  0; 

} 


/*  -  */ 

SuMRecord  *  psuGetMRecord ( SuMRecord  **  ppsuFirstMRecord,  int  iRIndex,  int  bMakeNew) 

{ 

SuMRecord  **  ppsuCurrMRec  =  ppsuFirstMRecord; 

//  Loop  looking  for  matching  index  number  or  end  of  list 
while  (bTRUE) 

{ 

//  Check  for  end  of  list 
if  ( *ppsuCurrMRec  ==  NULL) 
break; 

//  Check  for  matching  index  number 
if  ( (*ppsuCurrMRec) ->iRecordNum  ==  iRIndex) 
break; 

//  Move  on  to  the  next  record  in  the  list 
ppsuCurrMRec  =  & ( ( *ppsuCurrMRec) ->psuNextMRecord) ; 

} 


//  If  no  record  found  then  put  a  new  one  on  the  end  of  the  list 
if  ( ( *ppsuCurrMRec  ==  NULL)  &&  (bMakeNew  ==  bTRUE) ) 

{ 

//  Allocate  memory  for  the  new  record 

*ppsuCurrMRec  =  (SuMRecord  *) TmatsMalloc ( sizeof (SuMRecord) ) ; 
assert  (*ppsuCurrMRec  !=  NULL) ; 


//  Now  initialize  some  fields 
( *ppsuCurrMRec ) ->iRecordNum 
( *ppsuCurrMRec ) ->szDataSourceID 
( *ppsuCurrMRec ) ->szDataLinkName 
( * ppsuCurrMRec ) ->szBasebandSignalType 
( *ppsuCurrMRec ) ->psuNextMRecord 
} 


iRIndex; 
m_szEmpty; 
m_s z Empty  ; 
m_s z Empty ; 
NULL; 


return  *ppsuCurrMRec ; 

} 


/* - 

*  B  Records 


A-8-12 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


*/ 


int 


bDecodeBLine (char  *  szCodeName, 

{ 


char 

int 

int 

SuBRecord 


*  szCodeField; 
iTokens ; 
iRIdx; 

*  psuBRec; 


char  *  szDataltem,  SuBRecord  **  ppsuFir stBRecord) 


//  See  which  B  field  it  is 
szCodeField  =  strtok (szCodeName,  "\\") ; 
assert  ( szCodeField [ 0 ]  ==  'B'); 


/ /  Get  the  B  record  index  number 

iTokens  =  sscanf (szCodeField,  "%*lc-%i",  SiRIdx) ; 
if  (iTokens  ==  1) 

{ 

psuBRec  =  psuGetBRecord (ppsuFirstBRecord,  iRIdx,  bTRUE); 
assert (psuBRec  !=  NULL); 


else 

return  1; 

szCodeField  =  strtok (NULL,  "\\") ; 

//  DLN  -  Data  link  name 

if  ( strcasecmp ( szCodeField,  "DLN")  ==  0) 

{ 

psuBRec->szDataLinkName  =  (char  *) TmatsMalloc ( strlen ( szDataltem) +1 ) ; 
assert  (psuBRec->szDataLinkName  !=  NULL); 
strcpy (psuBRec->szDataLinkName,  szDataltem) ; 

}  //  end  if  DLN 

//  NBS\N  -  Number  of  buses 

else  if  (strncasecmp (szCodeField,  "NBS",3)  ==  0) 

{ 

szCodeField  =  strtok(NULL,  "\\") ; 

//  N  -  Number  of  channels 
if  (strcasecmp (szCodeField,  "N")  ==  0) 

{ 

psuBRec->iNumBuses  =  atoi ( szDataltem) ; 

} 

}  //  end  if  NBS 

return  0; 

} 


/*  -  */ 

SuBRecord  *  psuGetBRecord ( SuBRecord  **  ppsuFirstBRecord,  int  iRIndex,  int  bMakeNew) 

{ 

SuBRecord  **  ppsuCurrBRec  =  ppsuFirstBRecord; 

//  Loop  looking  for  matching  index  number  or  end  of  list 
while  (bTRUE) 

{ 

//  Check  for  end  of  list 
if  ( *ppsuCurrBRec  ==  NULL) 
break; 

//  Check  for  matching  index  number 
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if  ( (*ppsuCurrBRec) ->iRecordNum  ==  iRIndex) 
break; 

//  Move  on  to  the  next  record  in  the  list 
ppsuCurrBRec  =  &  (  ( *ppsuCurrBRec) ->psuNextBRecord) ; 
} 


//  If  no  record  found  then  put  a  new  one  on  the  end  of  the  list 
if  ( ( *ppsuCurrBRec  ==  NULL)  &&  (bMakeNew  ==  bTRUE) ) 

{ 

//  Allocate  memory  for  the  new  record 

*ppsuCurrBRec  =  (SuBRecord  * ) TmatsMalloc ( sizeof (SuBRecord) ) ; 
assert  (*ppsuCurrBRec  !=  NULL) ; 

//  Now  initialize  some  fields 
(*ppsuCurrBRec) ->iRecordNum 
(*ppsuCurrBRec) ->szDataLinkName 
(*ppsuCurrBRec) ->iNumBuses 
(*ppsuCurrBRec) ->psuNextBRecord 
} 


=  iRIndex; 

=  m_szEmpty; 
=  0; 

=  NULL; 


return  *ppsuCurrBRec ; 

} 


/*  - 

*  Connect  records  into  a  tree  structure 


//  Connect  R  records  with  the  coresponding  G  data  source  record. 

void  vConnectRtoG ( SuGRecord  *  psuFir stGRecord,  SuRRecord  *  psuFir stRRecord) 

{ 

SuRRecord  *  psuCurrRRec; 

SuGDataSource  *  psuCurrGDataSrc; 

//  Walk  through  the  R  record  linked  list,  looking  for  a  match  to  the 
//  appropriate  G  data  source  record. 
psuCurrRRec  =  psuFir stRRecord; 
while  (psuCurrRRec  !=  NULL) 

{ 


//  Step  through  the  G  data  source  records  looking  for  a  match 
psuCurrGDataSrc  =  psuFirstGRecord->psuFirstGDataSource; 
while  (psuCurrGDataSrc  !=  NULL) 

{ 

//  See  if  IDs  match 

if  (strcasecmp (psuCurrGDataSrc->szDataSourceID, 
psuCurrRRec->szDataSourceID)  ==  0) 

{ 

//  If  psuCurrGDataSrc->psuRRecord  !=  NULL  then  that  is  probably  an  error  in  the  TMATS  file 
psuCurrGDataSrc->psuRRecord  =  psuCurrRRec; 

//  If  R  can't  connect  to  more  than  one  G  then  we  could  break  here. 

}  //  end  if  match 

//  Get  the  next  G  data  source  record 

psuCurrGDataSrc  =  psuCurrGDataSrc->psuNextGDataSource ; 

}  //  end  while  walking  the  G  data  source  records 

//  Get  the  next  R  record 

psuCurrRRec  =  psuCurrRRec->psuNextRRecord; 
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}  //  end  while  walking  the  R  record  list 

return ; 

} 


/*  -  */ 

void  vConnectMtoR ( SuRRecord  *  psuFir stRRecord,  SuMRecord  *  psuFir stMRecord) 

{ 

SuMRecord  *  psuCurrMRec; 

SuRRecord  *  psuCurrRRec; 

SuRDataSource  *  psuCurrRDataSrc; 

//  Walk  through  the  M  record  linked  list,  looking  for  a  match  to  the 
//  appropriate  R  data  source  record. 
psuCurrMRec  =  psuFir stMRecord; 
while  (psuCurrMRec  !=  NULL) 

{ 

//  Walk  the  linked  list  of  R  records 
psuCurrRRec  =  psuFir stRRecord; 
while  (psuCurrRRec  !=  NULL) 

{ 

//  Walk  the  linked  list  of  R  data  sources 
psuCurrRDataSrc  =  psuCurrRRec->psuFir stDataSource ; 
while  (psuCurrRDataSrc  !=  NULL) 

{ 


//  See  if  IDs  match 

if  (strcasecmp (psuCurrRDataSrc->szDataSourceID, 

psuCurrMRec->szDataLinkName)  ==  0) 

{ 

//  If  psuCurrRDataSrc->psuMRecord  !=  NULL  then  that  is  probably  an  error  in  the  TMATS  file 
psuCurrRDataSrc->psuMRecord  =  psuCurrMRec; 

//  If  M  can't  connect  to  more  than  one  R  then  we  could  break  here. 

}  //  end  if  match 

//  Get  the  next  R  data  source  record 

psuCurrRDataSrc  =  psuCurrRDataSrc->psuNextRDataSource ; 

}  //  end  while  walking  the  R  data  source  records 

//  Get  the  next  R  record 

psuCurrRRec  =  psuCurrRRec->psuNextRRecord; 

} 


//  Get  the  next  M  record 

psuCurrMRec  =  psuCurrMRec->psuNextMRecord; 
}  //  end  while  walking  the  M  record  list 

return ; 

} 


/*  -  */ 

void  vConnectBtoM ( SuMRecord  *  psuFir stMRecord,  SuBRecord  *  psuFir stBRecord) 

{ 

SuBRecord  *  psuCurrBRec; 
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SuMRecord  *  psuCurrMRec; 

//  Walk  through  the  B  record  linked  list,  looking  for  a  match  to  the 
//  appropriate  M  data  source  record. 
psuCurrBRec  =  psuFir stBRecord; 
while  (psuCurrBRec  !=  NULL) 

{ 

//  Walk  the  linked  list  of  M  records 
psuCurrMRec  =  psuFir stMRecord; 
while  (psuCurrMRec  !=  NULL) 

{ 

//  See  if  IDs  match 

if  (strcasecmp (psuCurrMRec->szDataLinkName, 

psuCurrBRec->szDataLinkName)  ==  0) 

{ 

//  If  psuCurrMRecord->psuBRecord  !=  NULL  then  that  is  probably  an  error  in  the  TMATS  file 
psuCurrMRec->psuBRecord  =  psuCurrBRec; 

//  If  B  can't  connect  to  more  than  one  M  then  we  could  break  here. 

}  //  end  if  match 

//  Get  the  next  R  record 

psuCurrMRec  =  psuCurrMRec->psuNextMRecord; 

} 


//  Get  the  next  M  record 

psuCurrBRec  =  psuCurrBRec->psuNextBRecord; 
}  //  end  while  walking  the  M  record  list 

return ; 

} 


//  - 

//  The  enl 10 6_Decode_Tmats ( )  procedure  mallocO  's  a  lot  of  memory.  This 
//  procedure  walks  the  SuMemBlock  list,  freeing  memory  as  it  goes. 

void  110  6_CALL_DECL 

enI106_Free_TmatsInfo (SuTmatsInfo  *  psuTmatsInfo) 

{ 

SuMemBlock  *  psuCurrMemBlock; 

SuMemBlock  *  psuNextMemBlock; 

if  (psuTmatsInfo  ==  NULL) 
return ; 

//  Walk  the  linked  memory  list,  freely  freeing  as  we  head  down  the  freeway 
psuCurrMemBlock  =  psuTmatsInfo->psuFirstMemBlock; 
while  (psuCurrMemBlock  !=  NULL) 

{ 

//  Free  the  memory 

free  (psuCurrMemBlock->pvMemBlock) ; 

//  Free  the  memory  block  and  move  to  the  next  one 
psuNextMemBlock  =  psuCurrMemBlock->psuNextMemBlock; 
free (psuCurrMemBlock) ; 
psuCurrMemBlock  =  psuNextMemBlock; 

} 


//  Initialize  the  TMATS  info  data  structure 
memset (psuTmatsInfo,  0,  sizeof (SuTmatsInfo)); 
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return ; 

} 


//  - 

//  Allocate  memory  but  keep  track  of  it  for  enI106_Free_TmatsInfo ( )  later. 

void  *  TmatsMalloc ( size_t  iSize) 

{ 

void  *  pvNewBuff; 

SuMemBlock  **  ppsuCurrMemBlock; 

//  Malloc  the  new  memory 
pvNewBuff  =  malloc (iSize) ; 

//  Walk  to  (and  point  to)  the  last  linked  memory  block 
ppsuCurrMemBlock  =  &m_psuTmatsInfo->psuFirstMemBlock; 
while  ( *ppsuCurrMemBlock  !=  NULL) 

ppsuCurrMemBlock  =  & ( *ppsuCurrMemBlock) ->psuNextMemBlock; 

//  Populate  the  memory  block  struct 

*ppsuCurrMemBlock  =  (SuMemBlock  *) malloc (sizeof (SuMemBlock) ) ; 
(*ppsuCurrMemBlock) ->pvMemBlock  =  pvNewBuff; 

(*ppsuCurrMemBlock) ->psuNextMemBlock  =  NULL; 

return  pvNewBuff; 

} 


/*  - 

*  Write  procedures 

*  - *  i 

110 6_CALL_DECL  EnI106Status 

enI106_Encode_Tmats (SuI106Chl0Header  *  psuHeader, 

void  *  pvBuff, 

char  *  szTMATS) 

{ 

//  Channel  specific  data  word 
* (uint32_t  *)pvBuff  =  0; 

//  Figure  out  the  total  TMATS  message  length 
psuHeader->ulDataLen  =  strlen ( szTMATS)  +  4; 

//  Copy  TMATS  setup  info  to  buffer.  This  assumes  there  is  enough 

//  space  in  the  buffer  to  hold  the  TMATS  string. 
strcpy((char  *)pvBuff+4,  szTMATS); 

//  Make  the  data  buffer  checksum  and  update  the  header 
uAddDataFillerChecksum (psuHeader ,  (unsigned  char  *)pvBuff); 

return  I106_OK; 

} 
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APPENDIX  A-9  -  CONFIG.H 

/**************************************************************************** 
config.h  -  Define  features  and  OS  portability  macros 
Copyright  (c)  2006  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#ifndef  _config_h_ 

#define  _config_h_ 

#ifdef  _ cplusplus 

extern  "C"  { 

#endif 

//  .NET  2005  C++  wants  structures  that  are  passed  as  function  parameters  to  be  declared 
//  as  public.  .NET  2003  and  native  C  pukes  on  that.  C++  Interop  doesn't  seem  to  care. 

//  Grrrr...  Just  define  out  PUBLIC  for  now  but  leave  in  the  macro  logic  in  case  I  want 
//  to  revisit  this  someday.  Yeah,  right! 

//#if  _MSC_VER  >=  1400 
//fdefine  PUBLIC  public 
//#else 

#def ine  PUBLIC 
//#endif 

//  .NET  2005  (and  probably  earlier,  but  I'm  not  sure)  define  time_t  to  be  a  64  bit  value. 

//  And  by  default,  all  the  CRT  time  routines  are  the  64  bit  versions.  For  best  portability, 
//  time_t  is  assumed  to  be  a  32  bit  value.  The  following  #define  tells  .NET  to  use  32  bits 
//  as  the  default  time_t  size.  This  needs  to  be  set  in  the  project  properties.  This  forces 
//  a  puke  if  it  isn't  set. 

#if  _MSC_VER  >=  1400 

#if  ! defined (_USE  32BIT_TIME_T) 
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#pragma  message ( "WARNING  -  '_USE_32BIT_TIME_T '  not  set!") 

#endif 

fendif 

/*  The  POSIX  caseless  string  compare  is  strcasecmp ( ) .  MSVC  uses  the 
*  non-standard  stricmpO .  Fix  it  up  with  a  macro  if  necessary 
*/ 

#if  defined (_MSC_VER) 

#define  strcasecmp (si,  s2)  _stricmp(sl,  s2) 

#define  strncasecmp ( si ,  s2,  n)  _strnicmp ( si ,  s2,  n) 

#pragma  warning (disable  :  4996) 

#endif 

#def ine  I106_CALL_DECL 

#ifdef  _ cplusplus 

} 

#endif 

#endif 
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APPENDIX  A-10  -  STDINT.H 

/**************************************************************************** 
stdint.h  -  Define  standard  size  integers 
Copyright  (c)  2006  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 

#ifndef  _user_stdint_h 
fdefine  _user_stdint_h 

//  Modern  versions  of  GCC  usually  have  stdint.h  so  include  it  instead 
#if  defined ( _ GNUC  )  &&  ! defined ( _ DJGPP _ ) 


#include  <stdint.h> 

#endif 

//  The  DJGPP 

#if  defined (  DJGPP  ) 

typedef 

char 

int8  t; 

typedef 

short 

inti  6  t; 

typedef 

int 

int32  t ; 

typedef 

long  long 

int64  t ; 

typedef 

unsigned  char 

uint8  t; 

typedef 

unsigned  short 

uintl6  t 

typedef 

unsigned  int 

uint32  t 

typedef 

#endif 

unsigned  long  long 

uint64  t 

//  Define  specific  sized  variables  for  MSVC 
#if  defined (_WIN32 ) 

typedef  _ int8  int8_t; 
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typedef 

inti  6 

inti  6  t; 

typedef 

int32 

int32  t ; 

typedef 

int64 

int64  t ; 

typedef 

unsigned 

int8 

uint8  t; 

typedef 

unsigned 

inti  6 

uintl6  t 

typedef 

unsigned 

int32 

uint32  t 

typedef 

#endif 

unsigned 

int64 

uint64  t 

fendif 
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APPENDIX  B 

EXAMPLE  PROGRAM  -  CALCULATE  HISTOGRAM 

The  software  program,  shown  on  the  following  pages,  opens  a  Chapter  10  file  for 
reading,  calculates  a  running  count  of  each  packet  type  in  each  channel,  and  then  prints  out  these 
totals.  It  demonstrates  reading  individual  Chapter  10  packets,  and  parsing  them  based  on  packet 
type. 
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/* 


il06stat  -  Generate  histogram-like  statistics  on  a  Irig  106  data  file 
Copyright  (c)  2006  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 

*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

********************************************************************* 


#include 

#include 

#include 

#include 

#include 


<stdio . h> 
<stdlib . h> 
<string . h> 
<time . h> 
<assert . h> 


#include 

#include 

#include 

#include 


"conf ig . h" 

" stdint . h" 

" iriglO  6chl 0 . h" 
"il06  time.h" 


#include  "il06_decode_time.h" 
#include  "il06_decode_1553fl .h" 
#include  "il06  decode  tmats.h" 


/* 

*  Macros  and  definitions 


*/ 


#def ine  MAJ0R_VERSI0N  "Bl" 
#def ine  MIN0R_VERSI0N  "02" 

#if  (defined (bTRUE) 

#def ine  bTRUE  (1==1) 
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#define  bFALSE  (1==0) 
#endif 

/* 

*  Data  structures 


*/ 


/*  These  hold  the  number  of  messages  of  each  type  for  the  histogram.  */ 

//  1553  channel  counts 
typedef  struct 
{ 

unsigned  long 
unsigned  long 
unsigned  long 
unsigned  long 
unsigned  long 
int 

}  SuChanInfol553 ; 

//  Per  channel  statistics 
typedef  struct 
{ 


unsigned 

int 

iChanID; 

int 

iPrevSeqNum; 

unsigned 

long 

ulSeqNumError  ; 

unsigned 

char 

szChanType [32] 

unsigned 

char 

szChanName [ 32 ] 

SuChanInfol553 

*  psul 553Inf o; 

unsigned 

long 

ulUs er Defined; 

unsigned 

long 

uilrigTime; 

unsigned 

long 

ulAnalog; 

unsigned 

long 

ulTMATS; 

unsigned 

long 

ulEvents ; 

unsigned 

long 

ullndex; 

unsigned 

long 

ulPCM; 

unsigned 

long 

U1MPEG2; 

unsigned 

long 

ulUART; 

unsigned 

long 

ulOther ; 

}  SuChanlnfo; 

/* 

*  Module  data 


*/ 

int 
int 

/* 

*  Function  prototypes 


*/ 

void  vPrintCounts ( SuChanlnfo  *  psuChanlnfo,  FILE  *  ptOutFile); 

void  vPrintTmats (SuTmatsInfo  *  psuTmatsInfo,  FILE  *  ptOutFile) ; 

void  vProcessTmats (SuTmatsInfo  *  psuTmatsInfo,  SuChanlnfo  *  apsuChanlnf o [ ] ) ; 
void  vUsage (void) ; 


m_bLogRT2RT; 
m  bVerbose; 


ulTotallrigMsgs ; 
ulTotalBusMsgs ; 
aulMsgs [ 0x4000 ] ; 
aulErrs[0x4000] ; 
ulErrl 553Timeout  ; 
bRT2 RT Found; 
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int  main(int  argc,  char 

{ 


argv) 


//  Array  of  pointers  to  the  SuChanlnfo  structure 
static  SuChanlnfo  *  apsuChanlnfo [0x10000]; 


unsigned  char 
unsigned  char 
unsigned  char 
int 
int 

unsigned  long 
unsigned  long 

FILE 

int 

char 

char 

int 

unsigned  short 
unsigned  long 
unsigned  long 


abyFileStartTime [6] ; 
abyStartTime [ 6 ] ; 
abyStopTime [ 6] ; 
bFoundFileStartTime  =  bFALSE; 
bFoundDataStartTime  =  bFALSE; 
ulReadErrors ; 
ulTotal; 


*  ptOutFile; 
hI106In; 
szInFile [80] ; 
szOutFile [ 80 ] 
iArgldx; 
usPackedldx; 
ulBuffSize  = 
ulReadSize; 


//  Output  file  handle 

//  Input  file  name 
//  Output  file  name 


0L; 


unsigned  int 


uChanldx; 


EnI106Status 

SuI106Chl0Header 

Sul553Fl_CurrMsg 

SuTmatsInf o 

SuIrigl06Time 

struct  tm 

char 

char 

char 

char 


enStatus ; 

suI106Hdr; 

sul553Msg; 

suTmatsInfo; 

suIrigTime ; 

psuTmTime; 

szTime [50] ; 

szDateTimeFmt 

szDayTimeFmt 

szTimeFmt; 


"%m/%d/%Y  %H: %M: %S"  ; 

"%j : %H: %M: %S" ; 


unsigned  char 


pvBuf f 


NULL; 


//  Make  sure  things  stay  on  UTC 


putenv ( "TZ=GMT0" ) ; 
tzset  ( ) ; 


/* 

*  Initialize  the  channel  info  array  pointers  to  all  NULL 
*/ 


memset (apsuChanlnfo,  0,  sizeof (apsuChanlnfo) ) ; 
ulTotal  =  0L; 

ulReadErrors  =  0L; 

/* 

*  Process  the  command  line  arguements 
*/ 

if  (argc  <  2) 

{ 

vUsage ( ) ; 
return  1; 

} 
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m_bVerbose  =  bFALSE;  //No  verbosity 

m_bLogRT2RT  =  bFALSE;  //  Don't  keep  track  of  RT  to  RT 

szInFilefO]  =  ' \ 0 ' ; 

strcpy (szOutFile, "") ;  //  Default  is  stdout 

for  (iArgIdx=l;  iArgldxkargc ;  iArgIdx++) 

{ 

switch  (argv [iArgldx] [0] ) 

{ 

//  Handle  command  line  flags 
case  : 

switch  (argv [iArgldx] [1] ) 

{ 

case  ' r'  :  //  Log  RT  to  RT 

m_bLogRT2RT  =  bTRUE; 
break; 

case  ' v'  :  //  Verbose  switch 

m_bVerbose  =  bTRUE; 
break; 

default  ; 
break; 

}  /*  end  flag  switch  */ 
break; 

//  Anything  else  must  be  a  file  name 
default  : 

if  (szInFilefO]  ==  ' \ 0  '  )  strcpy (szInFile,  argv [ iArgldx] ) ; 
else  strcpy ( szOutFile, argv [ iArgldx] ) ; 

break; 

}  /*  end  command  line  arg  switch  */ 

}  /*  end  for  all  arguments  */ 

if  ( strlen  ( szInFile) ==0) 

{ 

vUsage  ( ) ; 
return  1; 

} 


/* 

*  Opening  banner 


*/ 


fprintf (stderr,  "\nI106STAT  "MAJOR_VERSION" . "MINOR_VERSION" \n" ) ; 
fprintf ( stderr ,  "Freeware  Copyright  (C)  2006  Irigl06 . org\n\n" )  ; 


/* 

*  Opens  file  and  get  everything  init'ed 


*/ 


//  Open  file  and  allocate  a  buffer  for  reading  data. 
enStatus  =  enI106ChlOOpen (&hI106In,  szInFile,  I106_READ) ; 
switch  (enStatus) 

{ 

case  1106  OPEN  WARNING  : 
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fprintf ( stderr ,  "Warning  opening  data  file  :  Status  =  %d\n",  enStatus) 
break; 

case  110 6_OK  : 

break; 
default  : 

fprintf ( stderr ,  "Error  opening  data  file  :  Status  =  %d\n",  enStatus); 

return  1; 

break; 

} 


enStatus  =  enI106_SyncTime (hI106In,  bFALSE,  0)  ; 
if  (enStatus  !=  I106_OK) 

{ 

fprintf ( stderr ,  "Error  establishing  time  sync  :  Status  =  %d\n",  enStatus); 
return  1; 

} 

//  If  output  file  specified  then  open  it 
if  (strlen (szOutFile)  !=  0) 

{ 

ptOutFile  =  fopen ( szOutFile, "w" ) ; 
if  (ptOutFile  ==  NULL) 

{ 

fprintf ( stderr ,  "Error  opening  output  file\n"); 
return  1; 

} 

} 

//No  output  file  name  so  use  stdout 
else 


ptOutFile  =  stdout; 

} 


fprintf ( stderr ,  "Computing  histogram ...\n"); 


/* 

*  Loop  until  there  are  no  more  message  whilst  keeping  track  of  all  the 

*  various  message  counts. 

*  _ 

*/ 


while  (1==1) 

{ 

//  Read  the  next  header 

enStatus  =  enI106Chl0ReadNextHeader (hI106In,  &suI106Hdr) ; 

//  Setup  a  one  time  loop  to  make  it  easy  to  break  out  on  error 
do 

{ 

if  (enStatus  ==  I106_EOF) 

{ 

break; 

} 

//  Check  for  header  read  errors 
if  (enStatus  !=  I106_OK) 

{ 

ulReadErrors++ ; 
break; 
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} 

//  Make  sure  our  buffer  is  big  enough,  size  *does*  matter 
if  (ulBuffSize  <  uGetDataLen (&suI106Hdr) ) 

{ 

pvBuff  =  realloc (pvBuff,  uGetDataLen ( &sul 10 6Hdr ))  ; 
ulBuffSize  =  uGetDataLen (&suI106Hdr)  ; 

} 


//  Read  the  data  buffer 
ulReadSize  =  ulBuffSize; 

enStatus  =  enI106Chl0ReadData (hI106In,  ulBuffSize,  pvBuff); 

//  Check  for  data  read  errors 
if  (enStatus  !=  I106_OK) 

{ 

ulReadErrors++ ; 
break; 

} 


//  If  this  is  a  new  channel,  malloc  some  memory  for  counts  and 
//  set  the  pointer  in  the  channel  info  array  to  it. 
if  (apsuChanlnfo [ sul 10 6Hdr . uChID]  ==  NULL) 

{ 

apsuChanlnfo [sul 10 6Hdr . uChID]  = 

(SuChanlnfo  *) malloc (sizeof (SuChanlnfo)  )  ; 
memset (apsuChanlnfo [ sull 06Hdr . uChID] ,  0,  sizeof  (SuChanlnfo) ) ; 
apsuChanlnfo [sul 10 6Hdr . uChID] ->iChanID  =  sull 06Hdr . uChID; 

//  Now  save  channel  type  and  name 
if  ( sull 06Hdr . uChID  ==  0) 

{ 

strcpy (apsuChanlnfo [ sull 06Hdr .uChID] ->szChanType,  "RESERVED" ) 
strcpy (apsuChanlnfo [ sull 06Hdr .uChID] ->szChanName,  "SYSTEM" ) ; 


else 

{ 

strcpy (apsuChanlnfo [ sull 06Hdr .uChID] ->szChanType,  "UNKNOWN" ) ; 
strcpy (apsuChanlnfo [ sull 06Hdr . uChID] ->szChanName,  "UNKNOWN" ) ; 
} 

} 


ulTotal++; 
if  (m_bVerbose) 

fprintf ( stderr ,  "%8.81d  Messages  \r", ulTotal) ; 

//  Save  data  start  and  stop  times 

if  ( (suI106Hdr .ubyDataType  !=  I106CH10_DTYPE_TMATS)  && 

( sul 10  6Hdr . ubyDataType  !=  I106CH10_DTYPE_IRIG_TIME) ) 

{ 

if  (bFoundDataStartTime  ==  bFALSE) 

{ 

memcpy((char  * ) abyStartTime,  (char  * ) sull 06Hdr . aubyRefTime,  6 
bFoundDataStartTime  =  bTRUE; 


else 

{ 

memcpy((char  * ) abyStopTime,  (char  *) sul 10 6Hdr . aubyRefTime,  6) 

} 

}  //  end  if  data  message 

//  Log  the  various  data  types 
switch  (suI106Hdr. ubyDataType) 

{ 
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case  I106CH10_DTYPE_USER_DEFINED  :  //  0x00 

apsuChanlnfo [sul 10  6Hdr . uChID] ->ulUserDef ined++; 
break; 

case  110 6CH1 0_DTYPE_TMATS  :  //  0x01 

apsuChanlnfo [suI106Hdr. uChID] ->ulTMATS++; 

//  Only  decode  the  first  TMATS  record 
if  (apsuChanlnfo [suI106Hdr. uChID] ->ulTMATS  !=  0) 

{ 

//  Save  file  start  time 

memcpy ( ( char  * ) SabyFileStartTime, 

(char  * ) sul 10 6Hdr . aubyRefTime,  6); 

//  Process  TMATS  info  for  later  use 

enll 06_Decode_Tmats ( &sull 06Hdr ,  pvBuff,  SsuTmatsInfo) ; 
if  (enStatus  !=  I106_OK) 
break; 

vProcessTmats ( SsuTmatsInfo,  apsuChanlnfo) ; 

} 

break; 

case  110 6CH1 0_DTYPE_RECORDING_EVENT  :  //  0x02 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->ulEvents++ ; 
break; 

case  110 6CH1 0_DTYPE_RECORDING_INDEX  :  //  0x03 

apsuChanlnfo [sul 10  6Hdr . uChID] ->ullndex+  +  ; 
break; 

case  1 1 0 6CH1 0_DT YPE_PCM  :  //  0x09 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->ulPCM+  +  ; 
break; 

case  1 1 0 6CH1 0_DTYPE_IRIG_TIME  :  //  0x11 

apsuChanlnfo [sul 10  6Hdr . uChID] ->ullr igTime++ ; 
break; 

case  1 1 0 6CH1 0_DT YPE_1 5 53_FMT_1  :  //  0x19 

//  If  first  1553  message  for  this  channel,  setup  the  1553  counts 
if  (apsuChanlnfo [ sul 10 6Hdr . uChID] ->psul 553Info  ==  NULL) 

{ 

apsuChanlnfo [ sul 10  6Hdr ,uChID]->psul553Info  = 
malloc (sizeof (SuChanInfol553) )  ; 
memset (apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul553Info, 

0x00,  sizeof (SuChanInfol553) ) ; 

} 


apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul 553Inf o->ulTotalIrigMsgs++ ; 

//  Step  through  all  1553  messages 

enStatus  =  enI106_Decode_Firstl553Fl (&suI106Hdr,  pvBuff,  &sul553Msg) ; 
while  (enStatus  ==  I106_OK) 

{ 

//  Update  message  count 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul553Info->ulTotalBusMsgs  +  +  ; 
usPackedldx  =  (sul553Msg.psuCmdWordl->uValue  »  5)  &  0x3FFF; 
apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul 553Inf o->aulMsgs [usPackedldx] +  + 

//  Update  the  error  counts 
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if  ( sul553Msg . psul 553Hdr->bMsgError  !=  0) 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul553Info->aulErrs[usPackedIdx]+  + 
if  ( sul553Msg . psul 553Hdr->bRespTimeout  !=  0) 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul 553Inf o->ulErr 1553Timeout++; 

//  Get  the  next  1553  message 

enStatus  =  enI106_Decode_Nextl553Fl (&sul553Msg) ; 

} 


//  If  logging  RT  to  RT  then  do  it  for  second  command  word 
if  ( sul553Msg . psul 553Hdr->bRT2RT  ==  1) 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul 553Inf o->bRT2RTFound  =  bTRUE ; 

if  (m_bLogRT2RT==bTRUE) 

{ 

usPackedldx  =  (sul553Msg.psuCmdWord2->uValue  »  5)  &  0x3FFF; 
apsuChanlnfo [ sul 10  6Hdr . uChID] ->psul 553Inf o->aulMsgs [usPackedldx] +  + 
}  //  end  if  logging  RT  to  RT 


break; 

case  1 1 0 6CH1 0_DT YPE_ANALOG  :  //  0x21 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->ulAnalog++ ; 
break; 

case  1 1 0 6CH1 0_DT YPE_VI DEO_FMT_0  :  //  0x40 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->ulMPEG2  +  +  ; 
break; 

case  1 1 0 6CH1 0_DT YPE_UART_FMT_0  :  //  0x50 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->ulUART++ ; 
break; 

default : 

apsuChanlnfo [ sul 10  6Hdr . uChID] ->ulOther+  +  ; 
break; 

}  //  end  switch  on  message  type 

}  while  (bFALSE) ;  //  end  one  time  loop 

//  If  EOF  break  out  of  main  read  loop 
if  (enStatus  ==  I106_EOF) 

{ 

break; 

} 


}  /*  End  while  */ 


/* 

*  Now  print  out  the  results  of  histogram. 


*/ 


//  vPrintTmats ( SsuTmatsInfo,  ptOutFile)  ; 

fprintf (ptOutFile, "\n=-=-=  Message  Totals  by  Channel  and  Type  =-=-=\n\n"); 
for  (uChanIdx=0;  uChanIdx<0xl000 ;  uChanIdx++) 

{ 

if  (apsuChanlnfo [uChanldx]  !=  NULL) 

{ 
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vPrintCounts (apsuChanlnf o [uChanldx]  ,  ptOutFile) ; 

} 


fprintf (ptOutFile, "=-=-=  File  Time  Summary  =-=-=\n\n"); 

enI106_Rel2IrigTime (hI106In,  abyFileStartTime,  SsuIrigTime) ; 
if  ( sulr igTime . enFmt  ==  I106_DATEFMT_DMY) 
szTimeFmt  =  szDateTimeFmt; 

else 

szTimeFmt  =  szDayTimeFmt ; 

psuTmTime  =  gmtime ( ( time_t  * ) &  ( suIrigTime . ulSecs) ) ; 
strftime (szTime,  50,  szTimeFmt,  psuTmTime); 
fprintf (ptOutFile, "File  Start  %s\n",  szTime); 

enI106_Rel2IrigTime (hI106In,  abyStartTime,  &suIrigTime) ; 
psuTmTime  =  gmtime (( time_t  *)&( suIrigTime . ulSecs) ) ; 
strftime (szTime,  50,  szTimeFmt,  psuTmTime); 
fprintf (ptOutFile, "Data  Start  %s\n",  szTime); 

enI106_Rel2IrigTime (hI106In,  abyStopTime,  SsuIrigTime) ; 
psuTmTime  =  gmtime (( time_t  *)&( suIrigTime . ulSecs) ) ; 
strftime (szTime,  50,  szTimeFmt,  psuTmTime); 
fprintf (ptOutFile, "Data  Stop  %s\n\n",  szTime); 

fprintf (ptOutFile, "\nTOTAL  RECORDS :  %101u\n\n",  ulTotal); 


/* 

*  Free  dynamic  memory. 
*/ 


free (pvBuff ) ; 
pvBuff  =  NULL; 

fclose (ptOutFile) ; 

return  0; 

} 


/*  -  */ 

void  vPrintCounts ( SuChanlnfo  *  psuChanlnfo,  FILE  *  ptOutFile) 

{ 

long  lMsgldx; 


//  Make  Channel  ID  line  lead-in  string 
fprintf (ptOutFile, "ChanID  %3d  :  %s  :  %s\n", 

psuChan!nfo->iChanID,  psuChan!nfo->szChanType,  psuChan!nfo->szChanName) ; 


if 

(psuChanInfo->ulTMATS  != 

:  0) 

fprintf (ptOutFile, " 

TMATS 

%101u\n". 

psuChanInfo->ulTMATS)  ; 

if 

(psuChanlnf o->ulEvents  ! 

=  0) 

fprintf (ptOutFile, " 

Events 

%101u\n" , 

psuChanlnf o->ulEvents ) ; 

if 

(psuChanlnf o->ulIndex  != 

^  0) 

fprintf (ptOutFile, " 

Index 

%101u\n". 

psuChanlnf o->ulIndex) ; 

if 

(psuChanlnf o->ul I r igTime 

:  !  =  0) 

fprintf (ptOutFile, " 

IRIG  Time 

%101u\n" , 

psuChanlnf o->ul!rigTime) 
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if  ( (psuChanInfo->psul 553Inf o  !=  NULL)  && 

(psuChanInfo->psul 553Inf o->ulTotalBusMsgs  !=  0)) 

{ 

//  Loop  through  all  RT,  TR,  and  SA  combinations 
for  (lMsgIdx=0;  lMsgIdx<0x4000 ;  lMsgIdx++) 

{ 

if  (psuChanInfo->psul553Info->aulMsgs [lMsgldx]  !=  0) 

{ 

fprintf (ptOutFile, "  RT  %2d  %c  SA  %2d  Msgs  %91u  Errs  %91u\n", 
(lMsgldx  >>  6)  &  OxOOlf, 

(lMsgldx  »  5)  &  0x0001  ?  'T'  :  'R', 

(lMsgldx  )  &  OxOOlf, 

psuChanInfo->psul553Info->aulMsgs [lMsgldx]  , 
psuChanInfo->psul553Info->aulErrs [lMsgldx] ) ; 

}  //  end  if  count  not  zero 
}  //  end  for  each  combination 

if  (psuChanInfo->psul553Info->bRT2RTFound  ==  bTRUE) 

{ 

fprintf (ptOutFile, " \n  Warning  -  RT  to  RT  transfers  found  in  the  data\n"); 


if  (m_bLogRT2RT  ==  bTRUE) 
fprintf (ptOutFile, 


II 

Message  total  is 

NOT  the  sum 

of  individual  RT  totals\n")  ; 

else 

fprintf (ptOutFile, 

II 

Some  transmit  RTs 

may  not  be 

shown\n" ) ; 

}  //  end  if  RT  to 

RT 

fprintf (ptOutFile,  " 

Totals  -  %ld  Message  in  %ld 

IRIG  RecordsXn", 

psuChanlnf o->psul 5 53 Inf o->ulTotalBusMsgs, 
psuChanlnf o->psul 5 53 Inf o->ulTotalIr igMsgs ) ; 

}  //  end  if  1553  messages 

if 

(psuChanlnf o->ulPCM  != 

0) 

fprintf (ptOutFile, " 

PCM 

%101u\n". 

psuChanInfo->ulPCM) ; 

if 

(psuChanlnf o->ulAnalog 

!=  0) 

fprintf (ptOutFile, " 

Analog 

%101u\n". 

psuChanlnf o->ulAnalog) ; 

if 

(psuChanlnf o->ulMPEG2 

!=  0) 

fprintf (ptOutFile, " 

MPEG  Video 

%101u\n". 

psuChanlnf o->ulMPEG2 ) ; 

if 

(psuChanInfo->ulUART  ! 

=  0) 

fprintf (ptOutFile, " 

UART 

%1 01u\n" , 

psuChanInfo->ulUART) ; 

if 

(psuChanlnf o->ulUserDef ined  !=  0) 

fprintf (ptOutFile, " 

User  Defined 

%101u\n" , 

psuChanlnf o->ulUser Defined) 

if 

(psuChanlnf o->ulOther 

!=  0) 

fprintf (ptOutFile, " 

Other  messages 

%101u\n". 

psuChanlnf o->ulOther )  ; 

fprintf (ptOutFile, "\n",  psuChanlnf o->ulOther ) ; 

return ; 

} 


/*  -  */ 

void  vPrintTmats (SuTmatsInfo  *  psuTmatsInf o,  FILE  *  ptOutFile) 
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{ 

int 

int 

int 

SuGDataSource 

SuRRecord 

SuRDataSource 


iGIndex; 

iRIndex; 

iRDsilndex; 

*  psuGDataSource; 

*  psuRRecord; 

*  psuRDataSource; 


//  Print  out  the  TMATS  info 
// - 


fprintf (ptOutFile, "\n=-=-=  Channel  Summary  =-=-=\n\n"); 

//  G  record 

fprintf (ptOutFile, "Program  Name  -  %s\n" , psuTmatsInf o->psuFirstGRecord->szProgramName) 
fprintf (ptOutFile, "IRIG  106  Rev  -  %s\n" , psuTmatsInf o->psuFirstGRecord->sz!r iglO 6Rev) ; 


fprintf (ptOutFile, "Channel  Type  Data  Source  \n"); 

fprintf  (ptOutFile,  " -  -  - \n"); 


//  Data  sources 

psuGDataSource  =  psuTmatsInf o->psuFirstGRecord->psuFirstGData Source ; 
do  { 

if  (psuGDataSource  ==  NULL)  break; 

//  G  record  data  source  info 

iGIndex  =  psuGDataSource->iDataSourceNum; 

//  R  record  info 

psuRRecord  =  psuGDataSource->psuRRecord; 
do  { 

if  (psuRRecord  ==  NULL)  break; 
iRIndex  =  psuRRecord->iRecordNum; 

//  R  record  data  sources 

psuRDataSource  =  psuRRecord- >psuFir stDataSource ; 
do  { 

if  (psuRDataSource  ==  NULL)  break; 
iRDsilndex  =  psuRDataSource->iDataSourceNum; 
fprintf (ptOutFile, "  %5i  ",  psuRDataSource->iTrackNumber ) ; 
fprintf (ptOutFile, "  %-12s",  psuRDataSource->szChannelDataType) ; 

fprintf (ptOutFile, "  %-20s",  psuRDataSource->szDataSourceID) ; 

fprintf (ptOutFile, "\n" ) ; 

psuRDataSource  =  psuRDataSource->psuNextRDataSource ; 

}  while  (bTRUE) ; 


psuRRecord  =  psuRRecord->psuNextRRecord; 
}  while  (bTRUE) ; 


psuGDataSource  = 

psuTmatsInfo->psuFir stGRecord->psuFir stGDataSource->psuNextGDataSource; 
}  while  (bTRUE) ; 

return ; 

} 


/*  -  */ 

void  vProcessTmats (SuTmatsInfo  *  psuTmatsInf o,  SuChanlnfo  *  apsuChanlnf o [ ] ) 

{ 

//  unsigned  uArrayldx; 


B-12 


RCC  Document  123-09,  IR1G  106  Chapter  10  Programming  Handbook,  March  2009 


//  unsigned  char  ul553ChanIdx; 

SuRRecord  *  psuRRecord; 

SuRDataSource  *  psuRDataSrc; 

//  Find  channels  mentioned  in  TMATS  record 
psuRRecord  =  psuTmatsInf o->psuFirstRRecord; 
while  (psuRRecord  !=  NULL) 

{ 

//  Get  the  first  data  source  for  this  R  record 
psuRDataSrc  =  psuRRecord->psuFirstDataSource; 
while  (psuRDataSrc  !=  NULL) 

{ 

//  Make  sure  a  message  count  structure  exists 
if  (apsuChanlnfo [psuRDataSrc->iTrackNumber ]  ==  NULL) 

{ 

//  SOMEDAY  PROBABLY  WANT  TO  HAVE  DIFFERENT  COUNT  STRUCTURES  FOR  EACH  CHANNEL  TYPE 

apsuChanlnfo [psuRDataSrc->iTrackNumber ]  =  malloc (sizeof (SuChanlnfo) ) ; 
memset (apsuChanlnfo [psuRDataSrc->iTrackNumber ] ,  0,  sizeof (SuChanlnfo) ) ; 
apsuChanlnfo [psuRDataSrc->iTrackNumber ] ->iChanID  =  psuRDataSrc->iTrackNumber 
} 


//  Now  save  channel  type  and  name 

strcpy (apsuChanlnfo [psuRDataSrc->iTrackNumber ] ->szChanType, 
psuRDataSrc->szChannelDataType)  ; 
strcpy (apsuChanlnfo [psuRDataSrc->iTrackNumber ] ->szChanName, 
psuRDataSrc->szDataSourceID) ; 

//  Get  the  next  R  record  data  source 
psuRDataSrc  =  psuRDataSrc->psuNextRDataSource ; 

}  //  end  while  walking  R  data  source  linked  list 

//  Get  the  next  R  record 

psuRRecord  =  psuRRecord->psuNextRRecord; 

}  //  end  while  walking  R  record  linked  list 

return ; 

} 


r 


* / 


void  vUsage(void) 

{ 

printf ("\nI106STAT  "MAJOR^VERSION" . "MINOR_VERSION"  " _ DATE _ "  " _ TIME _ "\n"), 

printf  ( "Print  totals  by  channel  and  message  type  from  a  Ch  10  data  file\n"); 

printf ( "Freeware  Copyright  (C)  2006  Irigl06.org\n\n"); 

printf ( "Usage :  il06stat  <input  file>  <output  file>  [flags] \n"); 


printf  ( " 
printf  ( " 
printf  ( " 


<filename>  Input/output  file  names\n"); 


-r 

-v 


Log  both  sides  of  RT  to  RT  transfers\n" ) ; 
VerboseXn" ) ; 
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APPENDIX  C 

EXAMPLE  PROGRAM  -  DECODE  TMATS 

The  following  software  program  opens  a  Chapter  10  file  for  reading,  extracts  the  TMATS  setup 
record,  and  displays  it  one  of  several  ways.  It  demonstrates  reading  Chapter  9  TMATS  packets,  and 
parsing  the  TMATS  attributes. 
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/*: 


idmptmat  -  Read  and  dump  a  TMATS  record  from  an  IRIG  106  Ch  10  data  file 
Copyright  (c)  2006  Irigl06.org 
All  rights  reserved. 

Redistribution  and  use  in  source  and  binary  forms,  with  or  without 
modification,  are  permitted  provided  that  the  following  conditions  are 
met : 


*  Redistributions  of  source  code  must  retain  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer. 

*  Redistributions  in  binary  form  must  reproduce  the  above  copyright 
notice,  this  list  of  conditions  and  the  following  disclaimer  in  the 
documentation  and/or  other  materials  provided  with  the  distribution. 

*  Neither  the  name  Irigl06.org  nor  the  names  of  its  contributors  may 
be  used  to  endorse  or  promote  products  derived  from  this  software 
without  specific  prior  written  permission. 

This  software  is  provided  by  the  copyright  holders  and  contributors 
"as  is"  and  any  express  or  implied  warranties,  including,  but  not 
limited  to,  the  implied  warranties  of  merchantability  and  fitness  for 
a  particular  purpose  are  disclaimed.  In  no  event  shall  the  copyright 
owner  or  contributors  be  liable  for  any  direct,  indirect,  incidental, 
special,  exemplary,  or  consequential  damages  (including,  but  not 
limited  to,  procurement  of  substitute  goods  or  services;  loss  of  use, 
data,  or  profits;  or  business  interruption)  however  caused  and  on  any 
theory  of  liability,  whether  in  contract,  strict  liability,  or  tort 
(including  negligence  or  otherwise)  arising  in  any  way  out  of  the  use 
of  this  software,  even  if  advised  of  the  possibility  of  such  damage. 

****************************************************************** 


#include 

#include 

#include 

#include 

#include 


<stdio . h> 
<stdlib . h> 
<string . h> 
<time . h> 
<assert .h> 


#include  "stdint.h" 


#include  "irigl06chl0.h" 
#include  "il06  decode  tmats.h" 


/* 

*  Macros  and  definitions 


*/ 

#def ine  MAJ0R_VERSI0N  "01" 
#def ine  MINOR_VERSION  "01" 

#if  (defined (bTRUE) 

#def ine  bTRUE  (1==1) 

#def ine  bFALSE  (1==0) 
#endif 
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/* 

*  Module  data 


*/ 


/* 

*  Function  prototypes 


*/ 

void  vDumpRaw (SuI106Chl0Header  *  psuI106Hdr,  void  *  pvBuff,  FILE  *  ptOutFile); 
void  vDumpTree (SuI106Chl0Header  *  psuI106Hdr,  void  *  pvBuff,  FILE  *  ptOutFile); 
void  vDumpChannel (SuI106Chl0Header  *  psuI106Hdr,  void  *  pvBuff,  FILE  *  ptOutFile) 
void  vUsage (void) ; 


/* - 

int  main(int  argc,  cha 

{ 

char 

char 

int 

FILE 

int 

int 

int 

unsigned  long 
int 

EnI106Status 

SuI106Chl0Header 

unsigned  char 


**  argv) 


szInFile [80] ; 
szOutFile [ 80 ]  ; 
iArgldx; 

*  ptOutFile; 
bRawOutput; 
bTreeOutput; 
bChannelOutput ; 
ulBuffSize  =  0L; 

iI106Chl0Handle; 
enStatus ; 
suI106Hdr; 

*  pvBuff  =  NULL; 


//  Input  file  name 
//  Output  file  name 

//  Output  file  handle 


*/ 


/*  Make  sure  things  stay  on  UTC  */ 

putenv  (  "TZ=GMT0" ) ; 
tzset ( )  ; 


/* 

*  Process  the  command  line  arguements 
*/ 


if  (argc  <  2)  { 

vUsage  ( ) ; 
return  1; 

} 

bRawOutput  =  bFALSE;  //No  verbosity 

bTreeOutput  =  bFALSE; 

bChannelOutput  =  bFALSE; 

szInFile [0]  =  ' \ 0 ' ; 

strcpy (szOutFile, "") ;  //  Default  is  stdout 

for  (iArgIdx=l;  iArgldxkargc ;  iArgIdx++) 

{ 


switch  (argv [iArgldx] [0]) 

{ 
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//  Handle  command  line  flags 
case  : 

switch  (argv [iArgldx] [1] ) 

{ 

case  ' r'  :  //  Raw  output 

bRawOutput  =  bTRUE; 
break; 


case  ' t'  :  //  Tree  output 

bTreeOutput  =  bTRUE; 
break; 

case  ' c'  :  //  Channel  summary 

bChannelOutput  =  bTRUE; 
break; 

default  ; 
break; 

}  //  end  flag  switch 
break; 

//  Anything  else  must  be  a  file  name 
default  ; 

if  (szInFilefO]  ==  ' \ 0 ' )  strcpy (szInFile,  argv [ iArgldx] ) 
else  strcpy ( szOutFile, argv [ iArgldx] ) 

break; 

}  //  end  command  line  arg  switch 
}  //  end  for  all  arguments 

if  ( strlen ( szInFile) ==0) 

{ 

vUsage  ( ) ; 
return  1; 

} 


//  Make  sure  at  least  on  output  is  turned  on 
if  ( (bRawOutput  ==  bFALSE)  && 

(bTreeOutput  ==  bFALSE)  && 
(bChannelOutput  ==  bFALSE) ) 
bChannelOutput  =  bTRUE; 


/* 

*  Opening  banner 


*/ 


fprintf (stderr,  "\nIDMPTMAT  "MAJOR_VERSION" . "MINOR_VERSION" \n" ) ; 
fprintf ( stderr ,  "Freeware  Copyright  (C)  2006  Irigl06 . org\n\n" ) ; 


/* 

*  Open  file  and  get  everything  init'ed 


*/ 


//  Open  file  and  allocate  a  buffer  for  reading  data. 

enStatus  =  enI106ChlOOpen (&iI106Chl0Handle,  szInFile,  I106_READ) ; 

switch  (enStatus) 

{ 

case  I106jOPEN_WARNING  : 

fprintf ( stderr ,  "Warning  opening  data  file  :  Status  =  %d\n". 
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break; 

case  110 6_OK  : 

break; 
default  : 

fprintf ( stderr ,  "Error  opening  data  file  :  Status  =  %d\n",  enStatus) 

return  1; 

break; 

} 


//  If  output  file  specified  then  open  it 
if  (strlen (szOutFile)  !=  0) 

{ 

ptOutFile  =  fopen ( szOutFile, "w" ) ; 
if  (ptOutFile  ==  NULL) 

{ 

fprintf ( stderr ,  "Error  opening  output  file\n"); 
return  1; 

} 

} 

//No  output  file  name  so  use  stdout 
else 

{ 

ptOutFile  =  stdout; 

} 


/* 

*  Read  the  TMATS  record 
*/ 


//  Read  the  next  header 

enStatus  =  enI106Chl0ReadNextHeader (iI106Chl0Handle,  &suI106Hdr) ; 

if  (enStatus  !=  I106_OK) 

{ 

fprintf ( stderr ,  "  Error  reading  header  :  Status  =  %d\n",  enStatus); 
return  1; 

} 

//  Make  sure  our  buffer  is  big  enough,  size  *does*  matter 
if  (ulBuffSize  <  uGetDataLen (&suI106Hdr) ) 

{ 

pvBuff  =  realloc  (pvBuff,  uGetDataLen (&suI106Hdr)  )  ; 
ulBuffSize  =  uGetDataLen (&suI106Hdr)  ; 

} 

//  Read  the  data  buffer 

enStatus  =  enI106Chl0ReadData (iI106Chl0Handle,  ulBuffSize,  pvBuff); 
if  (enStatus  !=  I106_OK) 

{ 

fprintf ( stderr ,  "  Error  reading  data  :  Status  =  %d\n",  enStatus); 
return  1; 

} 

if  ( sull 06Hdr . ubyDataType  !=  I106CH10_DTYPE_TMATS) 

{ 

fprintf ( stderr ,  "  Error  reading  data  :  first  message  not  TMATS"); 
return  1; 

} 

//  Generate  output 

fprintf  (ptOutFile,  " IDMPTMAT  "MAJOR^VERSION" . "MINOR_VERSION"\n" )  ; 
fprintf (ptOutFile,  "TMATS  from  file  %s\n\n",  szInFile) ; 
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if  (bRawOutput  ==  bTRUE) 

vDumpRaw (&suI106Hdr,  pvBuff,  ptOutFile); 

if  (bTreeOutput  ==  bTRUE) 

vDumpTree ( &sul 10 6Hdr ,  pvBuff,  ptOutFile); 

if  (bChannelOutput  ==  bTRUE) 

vDumpChannel (&suI106Hdr,  pvBuff,  ptOutFile) ; 

//  Done  so  clean  up 
free (pvBuff) ; 
pvBuff  =  NULL; 


fclose  (ptOutFile) ; 


return  0; 

} 


//  Output  the  raw,  unformated  TMATS  record 

void  vDumpRaw (SuI106Chl0Header  *  psuI106Hdr,  void  *  pvBuff,  FILE  * 

{ 

unsigned  long  IChrldx; 

char  *  achBuff  =  pvBuff; 

for  (IChrldx  =  0;  lChrIdx<psuI106Hdr->ulDataLen;  lChrIdx++) 
fputc (achBuff [ IChrldx] ,  ptOutFile) ; 

return ; 

} 


/* 


void  vDumpTree (SuI106Chl0Header  *  psuI106Hdr,  void  *  pvBuff,  FILE  * 


{ 

EnI106Status 

int 

int 

int 

SuTmatsInf o 
SuGDataSource 
SuRRecord 
SuRDataSource 


enStatus ; 

iGIndex; 

iRIndex; 

iRDsilndex; 

suTmatsInfo; 

*  psuGDataSource; 

*  psuRRecord; 

*  psuRDataSource; 


//  Process  the  TMATS  info 

enStatus  =  enI106_Decode_Tmats (psuI106Hdr,  pvBuff,  SsuTmatsInfo) 
if  (enStatus  !=  I106_OK) 

{ 

fprintf ( stderr ,  "  Error  processing  TMATS  record  :  Status  =  % 
return ; 

} 


//  Print  out  the  TMATS  info 
// - 

//  G  record 
fprintf (ptOutFile, 
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"(G)  Program  Name  -  %s\n" , suTmatsInf o . psuFirstGRecord->szProgramName) ; 
fprintf (ptOutFile, 

"(G)  IRIG  106  Rev  -  %s\n" , suTmatsInf o . psuFirstGRecord->szIr iglO 6Rev) ; 

//  Data  sources 

psuGDataSource  =  suTmatsInfo . psuFir stGRecord- >psuFirs tGDataSource ; 
do  { 

if  (psuGDataSource  ==  NULL)  break; 

//  G  record  data  source  info 

iGIndex  =  psuGDataSource->iDataSourceNum; 

fprintf (ptOutFile,  "  (G\\DSI-%i)  Data  Source  ID  -  %s\n", 

psuGDataSource->iDataSourceNum, 

suTmatsInfo . psuFir stGRecord->psuFir stGDataSource->szDataSourceID) ; 
fprintf (ptOutFile,  "  (G\\DST-%i)  Data  Source  Type  -  %s\n", 

psuGDataSource->iDataSourceNum, 

suTmatsInfo . psuFir stGRecord->psuFirstGDataSource->szDataSourceType) ; 
//  R  record  info 

psuRRecord  =  psuGDataSource->psuRRecord; 
do  { 

if  (psuRRecord  ==  NULL)  break; 
iRIndex  =  psuRRecord->iRecordNum; 

fprintf (ptOutFile,  "  (R-%i\\ID)  Data  Source  ID  -  %s\n", 

iRIndex,  psuRRecord->szDataSourceID) ; 

//  R  record  data  sources 

psuRDataSource  =  psuRRecord- >psuFir stDataSource ; 
do  { 

if  (psuRDataSource  ==  NULL)  break; 
iRDsilndex  =  psuRDataSource->iDataSourceNum; 
fprintf  (ptOutFile, 

"  (R-%i\\DSI-%i )  Data  Source  ID  -  %s\n", 

iRIndex,  iRDsilndex,  psuRDataSource->szDataSourceID) ; 
fprintf  (ptOutFile, 

"  (R-%i\\DST-%i )  Channel  Type  -  %s\n", 

iRIndex,  iRDsilndex,  psuRDataSource->szChannelDataType) ; 
fprintf (ptOutFile, 

"  (R-%i\\TKl-%i )  Track  Number  -  %i\n", 

iRIndex,  iRDsilndex,  psuRDataSource->iTrackNumber ) ; 
psuRDataSource  =  psuRDataSource->psuNextRDataSource ; 

}  while  (bTRUE) ; 

psuRRecord  =  psuRRecord->psuNextRRecord; 

}  while  (bTRUE) ; 


psuGDataSource  = 

suTmatsInfo . psuFir stGRecord->psuFir stGDataSource- >psuNextGDataSource; 
}  while  (bTRUE); 


return ; 

} 


/*  -  */ 

void  vDumpChannel (SuI106Chl0Header  *  psuI106Hdr,  void  *  pvBuff,  FILE  *  ptOutFile) 

{ 

EnI106Status  enStatus; 

int  iGIndex; 
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int 

int 

SuTmatsInf o 
SuGDataSource 
SuRRecord 
SuRDataSource 


iRIndex; 

iRDsilndex; 

suTmatsInfo; 

*  psuGDataSource; 

*  psuRRecord; 

*  psuRDataSource; 


//  Process  the  TMATS  info 

enStatus  =  enI106_Decode_Tmats (psuI106Hdr,  pvBuff,  SsuTmatsInfo) ; 
if  (enStatus  !=  I106_OK) 

{ 

fprintf ( stderr ,  "  Error  processing  TMATS  record  :  Status  =  %d\n",  enStatus); 
return ; 

} 


//  Print  out  the  TMATS  info 
// - 

//  G  record 
fprintf (ptOutFile, 

"Program  Name  -  %s\n" , suTmatsInfo . psuFirstGRecord->szProgramName) ; 
fprintf (ptOutFile, 

"IRIG  106  Rev  -  %s\n" , suTmatsInf o . psuFirstGRecord->szIr iglO 6Rev) ; 
fprintf (ptOutFile, 

"Channel  Type  Enabled  Data  Source  \n"); 

fprintf (ptOutFile, 

" -  -  -  - \  n  "  )  ; 


//  Data  sources 

psuGDataSource  =  suTmatsInfo . psuFirstGRecord->psuFirstGDataSource ; 
do  { 

if  (psuGDataSource  ==  NULL)  break; 

//  G  record  data  source  info 

iGIndex  =  psuGDataSource->iDataSourceNum; 

//  R  record  info 

psuRRecord  =  psuGDataSource->psuRRecord; 
do  { 

if  (psuRRecord  ==  NULL)  break; 
iRIndex  =  psuRRecord->iRecordNum; 

//  R  record  data  sources 

psuRDataSource  =  psuRRecord- >psuFir stDataSource ; 
do  { 

if  (psuRDataSource  ==  NULL)  break; 
iRDsilndex  =  psuRDataSource->iDataSourceNum; 

fprintf  (ptOutFile,  "  %5i  ",  psuRDataSource->iTrackNumber ) ; 
fprintf (ptOutFile,  "  %-12s",  psuRDataSource->szChannelDataType) ; 
fprintf (ptOutFile,  "  %-8s",  psuRDataSource->bEnabled  ?  "En"  :  "Dis") 

fprintf (ptOutFile,  "  %-20s",  psuRDataSource->szDataSourceID) ; 
fprintf (ptOutFile,  "\n"); 

psuRDataSource  =  psuRDataSource->psuNextRDataSource ; 

}  while  (bTRUE) ; 

psuRRecord  =  psuRRecord->psuNextRRecord; 

}  while  (bTRUE) ; 


psuGDataSource  = 

suTmatsInfo . psuFir stGRecord->psuFir stGDataSource->psuNextGDataSource; 
}  while  (bTRUE); 
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return ; 

} 


/*  -  */ 

void  vUsage(void) 

{ 

printf ("\nIDMPTMAT  -  IDMPTMAT  "MAJOR_VERSION" . "MINOR_VERSION"  " _ DATE _ "  " _ TIME 

printf ("Read  and  output  TMATS  record  from  a  Ch  10  data  file\n") ; 
printf ( "Freeware  Copyright  (C)  2006  Irigl06 . org\n\n" ) ; 
printf  ( "Usage :  idmptmat  <infile>  <outfile>  <flags>\n"); 


printf  ( " 

-c 

Output 

channel  summary  format  (default) \n" 

printf  ( " 

-t 

Output 

tree  view  formatin'1); 

printf  ( " 

-r 

Output 

raw  TMATS \n") ; 

return ; 

} 
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